Re: Get rid of the lib64 dir?
> 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)"
Yes, I would hope so. Most programs don't care which arch they are running on.
The few that do (uname, binutils, gcc) can usually be compiled to support
multiarch setups in a single binary.
> 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?
Someone who is doing development [for multiple achetectures] is unlikely to
want to install development versions over the installed system binaries. This
is a quick way to trash your system. Anyone who is compiling releasable
binaries (eg. debian packages) is probably going to want to do it in a clean
chroot anyway.
I do think that being able to develop for all archs on a multiarch system is a
big benefit. Given the answer to your previous question is yes, I don't see
any reason to actually need to install them in systemwide location.
> 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?
How do you then choose which to use?
I guess the main disadvantage is you now need to teach dpkg how to handle
multiarch binaries, not just libs.
Should both versions share a config file? How about things like /var?
Wouldn't you be better with a chroot if you actually need both versions
installed?
Paul
Reply to: