Andreas Jochens <[EMAIL PROTECTED]> 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
link.
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
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
