Andreas Jochens wrote:
On 04-May-11 11:19, Tollef Fog Heen wrote:Andreas Jochens wrote:My idea was simply that it should be easy to set up symlinks from the old standard locations like /lib and /usr/lib to the new architecture specific ones.Why?To be able to find the libraries for default architecture also at the standard locations /lib and /usr/lib and not only at the new multiarch-specific locations.
Again, why?You don't present any rationale for the files having to accessible through their legacy paths. Note that the dynamic linker will be taught how to find the multiarch libs in /usr/$(gcc -dumpmachine)/lib, so that won't be a problem.
What would you suggest to an admin to do with /usr/local/lib?
Avoid using it.
What would you suggest if somebody wants to install multiple architecure versions of a binary (when doing development and testing for multiarch machines this will make sense) or if someone wants to use mixed binaries from different architectures?
Use a chroot, use /usr/local, install in your home directory, depending on what and how you develop and test. Or have the binaries install as i386-linux-foo x86_64-linux-foo and have update-alternatives or similar available for switching between them. You will most likely need support in any non-trivial applications for doing that anyhow. Note that this is only a problem if you, say, want to run both an amd64 and an i386 mozilla, it's not a problem if you want to run an i386 mozilla and an amd64 emacs.
It still seems to be a straight forward approach to me to put all files which depend on a specific architecture in a single hierarchy. What would be the disadvantage this?
It removes the / vs /usr split, it creates new top-level directories, you don't have a good provision for something like /usr/local (since that will suddenly be split across multiple hierarchies). It's also a much bigger stray from the FHS than the current proposal.
This would require bigger root partitionsI do not think that root partitions would have to be bigger if it is done properly.
You don't say anything about what "is done properly" consists of. / should be as small as possible and only contain what's needed to get the system booting and /usr mounted to make the risk of something blowing up accidentially smaller. (Smaller disk area, smaller file system -> less chance of something making the system unbootable due to disk or file system errors.)
and is not supported by the current toolchain. amd-multiarch-2 is.True. I guess the linker would have to be made aware of the new library locations for the non-default architectures. The libraries for the default architecture would be accessible through the /lib and /usr/lib symlinks.
Again, this is so much more beautifully solved through the current, well-tested support in the toolchain rather than reinventing the wheel
You don't say why you want all those symlinks over the place.I do not want any symlinks if they can be avoided. I just consider it to be a good thing to have all architecture-dependend files in a single place. The symlinks from the old locations just provide compatibility with the current FHS.
Why do you care about the current FHS? It doesn't have provisions for multiarch, so it will have to be updated.
- tfheen