Re: Get rid of the lib64 dir?
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.
> >It should also be possible to simply change those
> >symlinks to point to a different default architecture, e.g. to change
> >/lib -> /i386-linux/lib to /lib -> /x86_64-linux/lib.
> >
> >Another point is that one should not have more architecture specific
> >entry points in the file system than necessary. The current multiarch
> >proposal has
> >
> >/lib/i386-linux
> >/usr/lib/i386-linux
> >/usr/local/i386-linux
> >...
>
> No, it does not. It has /lib/$(gcc -dumpmachine) and /usr/$(gcc
> -dumpmachine)/lib. /usr/local is the local admin's decision area.
What would you suggest to an admin to do with /usr/local/lib?
> >and maybe even
> >
> >/bin/i386-linux
> >/usr/bin/i386-linux
> >/usr/local/bin/i386-linux
> >...
> >
> >at a later stage.
>
> No. What multiarch proposal have you read that even opens up this
> possibility?
http://www.linuxbase.org/~taggart/fhs-multiarch.html:
"Questions
* Binaries - Can we assume that bin directories don't need to be
differentiated since users won't want more than one version of a binary
installed?(for example i386, ppc, ppc64 versions of ls should all do the
same thing)"
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?
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?
> This would require bigger root partitions
I do not think that root partitions would have to be bigger if it is
done properly.
> 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.
> 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.
Regards
Andreas Jochens
Reply to: