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

Bug#542865: Grant an FHS exception for the multiarch library directories



Package: debian-policy
Version: 3.8.3.0

We are approaching the point at which it will be useful to begin having
packages in the archive that install to the multiarch library paths
({/usr,}/lib/<triplet>), for use with the multiarch-capable package manager
that's in progress.  However, installing libraries to these paths instead of
directly under {/usr,}/lib is an FHS violation and therefore is currently a
Policy violation as well.

The following patch grants an exception to the FHS while strictly defining
the conditions under which these paths may be used (i.e.: biarch packages
must not use these paths), to ensure forward-compatibility with multiarch as
it's deployed.

I'm aware of only one package in the archive that's buggy with this change
in Policy, wine-unstable, which currently (in unstable) has amd64 packages
installing libraries to /usr/lib/i486-linux-gnu/; however, this package is
already violating Policy at present and is using these directories in a
manner inconsistent with the overall plan for multiarch and without
coordination.  I plan to file a serious bug against that package, pending
the outcome of discussion on this bug report.

The content of this particular change can also probably use refining - in
particular, we may wish to spell out use of /usr/lib/<triplet>/<package>
subdirs and /usr/include/<triplet> - but I thought it would be worth getting
feedback on this preliminary patch first.

---
 policy.sgml |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 0bf8253..9a28f5f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5584,6 +5584,35 @@ libbar 1 bar1 (>= 1.0-1)
               </item>
               <item>
                 <p>
+                  The requirement for libraries, including
+                  <file>libc.so.*</file>, to be located directly under
+                  <file>/lib{,32}</file> and <file>/usr/lib{,32}</file> is
+                  amended, permitting libraries to instead be installed to
+                  <file>/lib/<var>triplet</var></file> and
+                  <file>/usr/lib/<var>triplet</var></file>, where
+                  <tt><var>triplet</var></tt> is the value returned by
+                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
+                  architecture of the package.  Packages may <em>not</em>
+                  install libraries to any <var>triplet</var> path other
+                  than the one matching the architecture of that package;
+                  for instance, an <tt>Architecture: amd64</tt> package
+                  containing 32-bit x86 libraries may not install these
+                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
+                  <footnote>
+                    This is necessary in order to reserve the directories for
+                    use in cross-installation of library packages from other
+                    architectures, as part of the planned deployment of
+                    <tt>multiarch</tt>.
+                  </footnote>
+                </p>
+                <p>
+                  The execution time linker/loader, ld*, must still be made
+                  available in the existing location under /lib or /lib64
+                  since this is part of the ELF ABI for the architecture.
+                </p>
+              </item>
+              <item>
+                <p>
                   The requirement that
                   <file>/usr/local/share/man</file> be "synonymous"
                   with <file>/usr/local/man</file> is relaxed to a
-- 
1.6.3.1


Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: