Bug#664257: multiarch tuples are not documented/defined
On Fri, Apr 27, 2012 at 01:41:01AM -0500, Jonathan Nieder wrote:
> Hi Russ et al,
First, thanks Jonathan a lot for providing this patch. While this is
not the full story this gives us a better basis to document multiarch.
> - 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?
Another similar case are binaries optimised for a sub architecture.
(e.g. SSE2 optimised libraries).
> - what happens if an ABI document is just wrong? (For example, I
> have no idea whether the m68k psABI is accurate.)
For most practical purpose, the exact ABI is decided by the C compiler.
Thus we can expect gcc/clang upstream to deal with that.
> - 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?
Again, for most practical purpose, what matter is to be able to match the compiler
documentation with Debian documentation. If the compiler documentations states
that ABI=foo target "LSB IA64 4.1" and the Debian document says to target
"LSB IA64 4.1", then the developer know this is the right option without having
to read the ABI document.
> Improvements welcome, of course. What do you think?
I am very tempted to merge your patch except for the first paragraph:
> + <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>
Some words about architecture-independent packages are in order.
But outside that, is there objections to merging this patch ?
Seconds ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: