RE: multiarch/bi-arch status (ETA) question
> -----Original Message-----
> From: Stephen Frost [mailto:email@example.com]
> Sent: Tuesday, July 05, 2005 4:47 PM
> To: Lennart Sorensen
> Cc: David Wood; Hugo Mills; Goswin von Brederlow;
> Subject: Re: multiarch/bi-arch status (ETA) question
> * Lennart Sorensen (firstname.lastname@example.org) 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
> > 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.