Bug#885219: /lib64 provision added in 9.1.1 prohibits multilib libc
Control: tags -1 patch
Russ Allbery <rra@debian.org> writes:
> As explained by Aurelian Jarno:
>>> 9.1.1
>>> Only the dynamic linker may install files to /lib64/.
>> How is that supposed to work for the multilib glibc? For example
>> libc6-amd64:i386 installs all its libraries into /lib64. We don't want
>> to install these files in the multiarch path, as they will collide with
>> the libc6:amd64 package. This is actually forbidden by the same
>> paragraph of the policy (and that's a good thing).
>>
>> In the long term we should get ready of multilib now that we have
>> multiarch, but it seems it's not something we are ready to do yet.
> The best fix appears to be to exempt libc from this requirement (confirmed
> in a later message).
Here's a proposed diff. Seconds?
commit e0759206c2960f3fd6427583f10c4f87b39b152e (HEAD -> bug885219-rra)
Author: Russ Allbery <rra@debian.org>
Date: Mon Dec 25 18:06:25 2017
Allow libc to install files in /lib64
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 7d9e20a..d7c4956 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -35,7 +35,8 @@ Debian Policy. The following exceptions to the FHS apply:
character.
3. The requirement for amd64 to use ``/lib64`` for 64 bit binaries is
- removed. Only the dynamic linker is allowed to use this directory.
+ removed. Only the dynamic linker and libc are allowed to use this
+ directory.
4. The requirement for object files, internal binaries, and libraries,
including ``libc.so.*``, to be located directly under ``/lib{,32}``
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: