RE: multiarch/bi-arch status (ETA) question
"What's the reason for having both versions of a given app installed?"
To satisfy multiple dependencies that are "must-be-<arch>"
From: Stephen Frost [mailto:firstname.lastname@example.org]
Sent: Tuesday, July 05, 2005 1:47 PM
To: Lennart Sorensen
Cc: David Wood; Hugo Mills; Goswin von Brederlow;
Subject: Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen (email@example.com) wrote:
> Of course there is also the issue of how to deal with calling the 32
> 64bit version of program x if you have both versions installed.
> 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.
> 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
> all package (which would of course be trivial to handle). Do we
> the files from the older version somewhere, and then remove it when
> 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.