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

Bug#742756: multi-arch and system-dependent header files



On Wed, Mar 26, 2014 at 03:47:22PM -0700, Russ Allbery wrote:
> Bill Allombert <ballombe@debian.org> writes:
> 
> > <https://wiki.debian.org/Multiarch/Implementation> says:
> 
> > << If your -dev package contains headers which vary across architectures
> > then it cannot be marked as Multi-Arch: same until a policy decision is
> > made about architecture-dependant headers and the toolchain is
> > updated. >>
> 
> > As far as I understand, the current practice for handling them is to
> > move them to /usr/include/<triplet>/ and the C preprocessor will look at
> > this directory.
> 
> That's correct.
> 
> > Probably policy should say something about that.
> 
> Agreed.

OK, this is a first attempt (with 25 line of context).

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
diff --git a/policy.sgml b/policy.sgml
index bd9eb73..aa5408a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -6955,50 +6955,61 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
               <item>
                 <p>
                   The requirement for object files, internal binaries, and
                   libraries, including <file>libc.so.*</file>, to be located
                   directly under <file>/lib{,32}</file> and
                   <file>/usr/lib{,32}</file> is amended, permitting files
                   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_MULTIARCH</tt> for the
                   architecture of the package.  Packages may <em>not</em>
                   install files 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/i386-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 requirement for C and C++ headers files to be
+                  accessible through the search path
+                  <file>/usr/include/</file> is amended, permitting files to
+                  be accessible through the search path
+                  <file>/usr/include/<var>triplet</var></file> where
+                  <tt><var>triplet</var></tt> is as above.  <footnote>
+                    This is necessary for architecture-dependant headers
+                    file to coexist in a <tt>multiarch</tt> set up.
+                  </footnote>
+                </p>
+                <p>
                   Applications may also use a single subdirectory under
                   <file>/usr/lib/<var>triplet</var></file>.
                 </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
                   recommendation</p>
               </item>
               <item>
                 <p>
                   The requirement that windowmanagers with a single
                   configuration file call it <file>system.*wmrc</file>
                   is removed, as is the restriction that the window
                   manager subdirectory be named identically to the
                   window manager name itself.
                 </p>
               </item>

Reply to: