[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 


Reply to: