* Lennart Sorensen (lsorense@csclub.uwaterloo.ca) 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. > 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
Attachment:
signature.asc
Description: Digital signature