Bug#664257: multiarch tuples are not documented/defined
Hi Russ et al,
The patch below documents the Architecture field. It doesn't cover
architecture tuples yet, but presumably once the description of
architectures is in good shape it would not be hard to add a mapping
from Debian arches to pathnames to section 9.1.5.
Some concerns:
- what should the normative content be? It would not be too strange
to put a firmware file that happens to be a MIPS binary in an
"Architecture: i386" or "Architecture: all" package, and I think
it is important to keep permitting that.
How should this be worded to permit that sort of thing while still
making it clear that a package installing MIPS DSOs as NSS plugins
under /usr/lib/nss ought to use architecture: mips or mipsel?
- what happens if an ABI document is just wrong? (For example, I
have no idea whether the m68k psABI is accurate.)
- the notion of ABI in the multiarch sense is surprisingly
slippery. Corrections and clarifications to the definition used
below could be useful --- the important notion of "which objects
can share a process image?" didn't manage to find its way in.
- is it okay to rely so heavily on external resources? Is it safe to
assume that the reader can look up link targets when needed, or
does link text need to be unambiguous? Would we need to include a
summary or copy of some of the cited standards in case they
disappear?
I didn't include the full table from [1], though it might make a nice
appendix. If the text is working as it ought to, then it should be
possible to infer the omitted values (endianness, sizeof(long), and so
on) from the descriptions below.
My hope is that this documentation might make it easier to explain the
purpose and semantics of the Multiarch: field later.
Improvements welcome, of course. What do you think?
[1] http://wiki.debian.org/Multiarch/Tuples
policy.sgml | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 191 insertions(+), 1 deletion(-)
diff --git a/policy.sgml b/policy.sgml
index 52dbb26a..1a7ed748 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1423,6 +1423,25 @@
</sect>
+ <sect id="architecture">
+ <heading>Architecture</heading>
+
+ <p>
+ Every Debian binary package must have an <tt>Architecture</tt>
+ control field which describes the ABI used by dynamically-linked
+ binaries and public shared libraries in the package and
+ packages it interacts with. For example, packages built to run
+ on a 32-bit Intel-architecture GNU/Linux system would use an
+ <tt>Architecture</tt> of <tt>i386</tt>.
+ </p>
+
+ <p>
+ Unless otherwise specified, dependencies specified using the
+ <tt>Suggests</tt>, <tt>Depends</tt>, <tt>Recommends</tt>, and
+ <tt>Pre-Depends</tt> fields refer to packages of the same
+ architecture.
+ </p>
+ </sect>
</chapt>
@@ -2945,7 +2964,7 @@ Package: libc6
<list>
<item>
A unique single word identifying a Debian machine
- architecture as described in <ref id="arch-spec">.
+ architecture as described in <ref id="arch-short-name">.
</item>
<item>
An architecture wildcard identifying a set of Debian
@@ -3052,6 +3071,177 @@ Package: libc6
See <ref id="debianrules"> for information on how to get
the architecture for the build process.
</p>
+
+ <sect2 id="arch-short-name">
+ <heading>Debian architecture names</heading>
+
+ <p>
+ Binary programs and public shared libraries in binary
+ packages must use the appropriate binary format,
+ basic operating system interface, and procedure linkage
+ convention declared in the <tt>Architecture</tt> field.
+ <footnote>
+ The <tt>Architecture</tt> field indicates the system
+ ABI but not the precise instruction set or system
+ libraries used: the former is generally determined by
+ convention with exceptions noted in the package
+ description or using hwcap paths, and the latter
+ expressed using package dependencies.
+ </footnote>
+ </p>
+
+ <p>
+ <taglist>
+ <tag><tt>alpha</tt></tag>
+ <item>
+ GNU/Linux,
+ <url id="http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/ARH9MBTE/TITLE.HTM";
+ name="Tru64 5.1 Calling Standard for Alpha Systems">
+ </item>
+
+ <tag><tt>arm</tt></tag>
+ <item>
+ GNU/Linux, little endian,
+ <url id="http://infocenter.arm.com/help/topic/com.arm.doc.dui0041c/BGBGFIDA.html";
+ name="ARM Procedure Call Standard (obsolete)">
+ </item>
+
+ <tag><tt>armel</tt></tag>
+ <item>
+ GNU/Linux, little endian,
+ <url id="https://sourcery.mentor.com/GNUToolchain/kbentry39";
+ name="ARM GNU/Linux ABI 1.0">
+ </item>
+
+ <tag><tt>armhf</tt></tag>
+ <item>
+ GNU/Linux, little endian,
+ <url id="https://sourcery.mentor.com/GNUToolchain/kbentry39";
+ name="ARM GNU/Linux ABI 1.0">,
+ except that function calls use VFP Register Arguments
+ as described in the
+ <url id="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042a/IHI0042A_aapcs.pdf";
+ name="Procedure Call Standard for the ARM Architecture">,
+ section 6.
+ </item>
+
+ <tag><tt>hppa</tt></tag>
+ <item>
+ <url id="http://wiki.parisc-linux.org/ToolChain";
+ name="PA-RISC Linux 32-bit ELF">
+ </item>
+
+ <tag><tt>hurd-i386</tt></tag>
+ <item>
+ GNU/Hurd,
+ <url id="http://refspecs.linuxbase.org/elf/abi386-4.pdf";
+ name="Intel IA-32 psABI">,
+ 16-byte stack alignment
+ </item>
+
+ <tag><tt>kfreebsd-i386</tt></tag>
+ <item>
+ GNU/kernel of FreeBSD,
+ <url id="http://refspecs.linuxbase.org/elf/abi386-4.pdf";
+ name="Intel IA-32 psABI">,
+ 16-byte stack alignment
+ </item>
+
+ <tag><tt>i386</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-IA32/LSB-Core-IA32/elf-ia32.html";
+ name="LSB IA32 4.1">,
+ 16-byte stack alignment
+ </item>
+
+ <tag><tt>ia64</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-IA64/LSB-Core-IA64/elf-ia64.html";
+ name="LSB IA64 4.1">
+ </item>
+
+ <tag><tt>m68k</tt></tag>
+ <item>
+ GNU/Linux, Motorola 68000 psABI (ISBN 978-0138776633)
+ </item>
+
+ <tag><tt>mips</tt></tag>
+ <item>
+ GNU/Linux, big endian,
+ <url id="http://refspecs.linuxbase.org/elf/mipsabi.pdf";
+ name="MIPS o32 ABI">
+ </item>
+
+ <tag><tt>mipsel</tt></tag>
+ <item>
+ GNU/Linux, little endian,
+ <url id="http://refspecs.linuxbase.org/elf/mipsabi.pdf";
+ name="MIPS o32 ABI">
+ </item>
+
+ <tag><tt>powerpc</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC32/LSB-Core-PPC32/elf-ppc32.html";
+ name="LSB PPC32 4.1">
+ </item>
+
+ <tag><tt>powerpcspe</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC32/LSB-Core-PPC32/elf-ppc32.html";
+ name="LSB PPC32 4.1">,
+ except that function calls and relocations use the e500
+ convention described in the ATR-SPE portion of the
+ <url id="https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0.tgz";
+ name="Power Architecture 32-bit ABI Supplement 1.0">
+ </item>
+
+ <tag><tt>ppc64</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC64/LSB-Core-PPC64/elf-ppc64.html";
+ name="LSB PPC64 4.1">
+ </item>
+
+ <tag><tt>s390</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-S390/LSB-Core-S390/elf-s390.html";
+ name="LSB S390 4.1">
+ </item>
+
+ <tag><tt>s390x</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-S390X/LSB-Core-S390X/elf-s390x.html";
+ name="LSB S390X 4.1">
+ </item>
+
+ <tag><tt>sparc</tt></tag>
+ <item>
+ GNU/Linux,
+ <url id="http://www.sparc.com/standards/psABI3rd.pdf";
+ name="32-bit SPARC psABI">
+ </item>
+
+ <tag><tt>sparc64</tt></tag>
+ <item>
+ GNU/Linux,
+ <url id="http://www.sparc.com/standards/64.psabi.1.35.ps.Z";
+ name="64-bit SPARCv9 psABI">
+ </item>
+
+ <tag><tt>kfreebsd-amd64</tt></tag>
+ <item>
+ GNU/kernel of FreeBSD,
+ <url id="http://x86-64.org/documentation/abi.pdf";
+ name="AMD64 psABI">
+ </item>
+
+ <tag><tt>amd64</tt></tag>
+ <item>
+ <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-AMD64/LSB-Core-AMD64/elf-amd64.html";
+ name="LSB AMD64 4.1">
+ </item>
+ </taglist>
+ </p>
+ </sect2>
</sect1>
<sect1 id="f-Essential">
--
1.7.10
Reply to: