> -----Original Message----- > From: Stephen Frost [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 05, 2005 4:47 PM > To: Lennart Sorensen > Cc: David Wood; Hugo Mills; Goswin von Brederlow; > debian-amd64@lists.debian.org > Subject: Re: multiarch/bi-arch status (ETA) question > > * Lennart Sorensen ([EMAIL PROTECTED]) wrote: > > Of course there is also the issue of how to deal with > calling the 32 > > or 64bit version of program x if you have both versions installed. > > Perhaps a helper tool to say run64bit version of x would deal with > > that, and your idea of having symlinks in the original > location to a > > default version would deal well with that. If not > specified you run > > the one that has the symlink. > > What's the reason for having both versions of a given app installed? > I'm pretty sure it was decided that was a bad idea and that > there wasn't any good use case for it and so we weren't going > to try and support it. > It just doesn't make sense.
The only reason is to be able to run both of them at your discretion. > > > Of course then there is things like data files in > /usr/share which are > > not architecture specific. If you install the same version > of both 32 > > and 64bit for a package, then the files should match and > just keeping > > one copy should be fine. If for some reason you install a > different > > version of one of them (as would happen during upgrades) how do we > > resolve those files? They aren't always seperated into an > > architecture all package (which would of course be trivial > to handle). > > Do we divert the files from the older version somewhere, and then > > remove it when the older one is upgraded to match the newer > one? No > > point wasting disk space on identical files after all. > > This is only an issue with libraries, and /usr/share should > have things which are arch-independent and /usr/lib/<blah> > should have arch-dependent things. If packages don't follow > that today then they're broken already and need to be fixed. > It is true that there can't be multiple things installed with > files in the same place, so any /usr/share usage in libraries > needs to be split out in a -common package for that library. > This isn't an issue for programs because we're not interested > in supporting the unjustified case for having the same > program both 32bit and 64bit at the same time. > > Thanks, > > Stephen >