Re: Get rid of the lib64 dir?
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
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
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
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 partitions
I do not think that root partitions would have to be bigger if it is
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
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.