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

Re: Compatibility between Debian amd64 and other distributions

Andreas Jochens <aj@andaco.de> writes:

> Hello,
> On 06-Sep-23 02:50, Goswin von Brederlow wrote:
>> FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non
>> Debian distributions follow that line.
> Gentoo uses basically the same setup as Debian, i.e. it installs 64-bit 
> libraries in /usr/lib and it has a symlink from /usr/lib64 to /usr/lib.
>> Steve Langasek had concerns about side-effects:
>> > That probably means that a change for this would not be accepted
>> > into etch, since fiddling library paths may have unexpected
>> > side-effects and glibc is already frozen.
>> So far I have seen none.
> The proposed glibc patch will break the installer. The installer does not 
> have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. 
> It has been decided following some discussion.) 
> The proposed patch changes the 64-bit library access paths used by glibc, 
> i.e. (s)libdir, from (/usr)/lib to (/usr)/lib64. With this change, the 
> /usr/lib64 symlink would become a necessary requirement for things to work
> properly. Currently, the distribution works even without the /usr/lib64
> symlink.

Ok, so we have to also set

udeb_slibdir = /lib
udeb_libdir = /usr/lib

No biggy.

>> Now I guess the release-team has to make a decision how important the
>> FHS and compatibility is to Debian.
> The proposed patch may improve compatibility with Redhat or Novell
> but it does not improve compliance with the FHS.
> The relevant parts of the FHS 2.3 are:
> A) "/lib : Essential shared libraries and kernel modules
>     Purpose: The /lib directory contains those shared library images 
>     needed to boot the system and run the commands in the root filesystem,
>     ie. by binaries in /bin and /sbin.
> B) "/lib<qual> : Alternate format essential shared libraries (optional)
>     Purpose: There may be one or more variants of the /lib directory on 
>     systems which support more than one binary format requiring separate 
>     libraries. [Footnote:] This is commonly used for 64-bit or 32-bit 
>     support on systems which support multiple binary formats, but require 
>     libraries of the same name. In this case, /lib32 and /lib64 might be 
>     the library directories, and /lib a symlink to one of them."
> C) "/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
>     The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 
>     64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries 
>     in /lib. The 64-bit architecture IA64 must place 64-bit libraries in 
>     /lib.
>     Rationale: This is a refinement of the general rules for /lib<qual> 
>     and /usr/lib<qual>. The architectures PPC64, s390x, sparc64 and 
>     AMD64 support support [sic!] both 32-bit (for s390 more precise 31-bit) 
>     and 64-bit programs. Using lib for 32-bit binaries allows existing 
>     binaries from the 32-bit systems to work without any changes: 
>     such binaries are expected to be numerous. IA-64 uses a different
>     scheme, reflecting the deprecation of 32-bit binaries (and hence 
>     libraries) on that architecture."
> Summarized, Debian and Gentoo comply with A) and B) but not with C) 
> while Redhat and Novell comply with B) and C) but not with A). 

I believe the installed Debian system conforms with A, B and C because
lib and lib64 are the same for us. Debian (and gentoo) are unique in
that. I don't think the FHS says anywhere that /lib64 must not be a

B specifically allows for lib to be a link without invalidating A so
the reverse should be the same.

> The FHS 2.3 rule C) mandates that 32-bit libraries have to be stored in 
> (/usr)/lib on amd64. To implement this in Debian would be difficult 
> because almost every library package would have to be changed to install
> the native library files in a separate /usr/lib64 directory instead 
> of the usual /usr/lib.
> The other Debian ports have their native libraries installed in /usr/lib. 
> Many packages rely on this fact. Many things, especially during the build
> process, will break if the native libraries are not in /usr/lib. 

Not really. Sources are a bit more resiliant than that. For one thing
SuSe and RH have /usr/lib64 and it compiles there.

What would break is the install process because the debian/rules or
debian/*.install (the debhelper files) list /usr/lib. So

> It would be a _lot_ of work to change the whole distribution to use 
> /usr/lib64 instead of /usr/lib as the location of the native libraries.

nobody wants that. It was always said that changing things to
(/usr)/lib64 will be difficult to transition and just wasted effort if
it gets changed to (/usr)/lib/x86_64-linux-gnu as per multiarch
proposal anyway.

> Regards
> Andreas Jochens


Reply to: