Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
Guillem Jover <guillem@debian.org> writes:
> On Thu, 2010-06-03 at 00:06:39 +0200, Guillem Jover wrote:
>> From a comment somewhere else I think you understand it now, but anyway
>> just to make sure, it allows adding new architectures in dpkg w/o
>> needing to recreate the source package from its internal representation
>> where the wildcards are located (debian/control) to the external ones
>> (.dsc, .changes, and those percolated to meta-indices, etc).
> Actually I think it's me who didn't understand. :) I just rememebered
> commenting about this in [0], so assumed it was the same. Anyway this
> seems to be a mix of the original patch, and my comment, which do not
> quite match together as they kind of contradict each other. Back then it
> was a comment to try to correct the wording in the original patch which
> was mentioning explicitly something that was not quite right. I don't
> think this needs to be spelled out in policy either way, it's just an
> implementation detail. The only thing that might make sense to mention
> as rationale is why the wildcards don't get expanded from the internal
> source representation to to the external ones, as mentioned above.
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687#47>
Okay, here's another try at this patch that removes some extraneous
information that it sounds like we shouldn't get into, from this message
and your other message, and tries to simplify the wording to address the
issue raised in the message whose URL is given above.
diff --git a/policy.sgml b/policy.sgml
index af00c0e..36c7a1f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2735,41 +2735,62 @@ Package: libc6
<tt>Architecture</tt> field can include the following sets of
values:
<list>
- <item>A unique single word identifying a Debian machine
- architecture as described in <ref id="arch-spec">.
- <item><tt>all</tt>, which indicates an
- architecture-independent package.
- <item><tt>any</tt>, which indicates a package available
- for building on any architecture.
- <item><tt>source</tt>, which indicates a source package.
+ <item>
+ A unique single word identifying a Debian machine
+ architecture as described in <ref id="arch-spec">.
+ </item>
+ <item>
+ An architecture wildcard identifying a set of Debian
+ machine architectures, see <ref id="arch-wildcard-spec">.
+ <tt>any</tt> matches all Debian machine architectures
+ and is the most frequently used.
+ </item>
+ <item>
+ <tt>all</tt>, which indicates an
+ architecture-independent package.
+ </item>
+ <item>
+ <tt>source</tt>, which indicates a source package.
+ </item>
</list>
</p>
<p>
In the main <file>debian/control</file> file in the source
- package, this field may contain the special value
- <tt>any</tt>, the special value <tt>all</tt>, or a list of
- architectures separated by spaces. If <tt>any</tt> or
- <tt>all</tt> appear, they must be the entire contents of the
- field. Most packages will use either <tt>any</tt> or
- <tt>all</tt>. Specifying a specific list of architectures is
- for the minority of cases where a program is not portable or
- is not useful on some architectures, and where possible the
- program should be made portable instead.
+ package, this field may contain the special value <tt>all</tt>
+ or a list of specific and wildcard architectures separated by
+ spaces. If <tt>all</tt> appears, that value must be the
+ entire contents of the field. Most packages will use
+ either <tt>any</tt> or <tt>all</tt>.
+ </p>
+
+ <p>
+ Specifying a specific list of architectures indicates that the
+ source will build an architecture-dependent package only on
+ architectures included in the list. Specifying a list of
+ architecture wildcards indicates that the source will build an
+ architecture-dependent package on only those architectures
+ that match any of the specified architecture wildcards.
+ Specifying a list of architectures or architecture wildcards
+ other than <tt>any</tt> is for the minority of cases where a
+ program is not portable or is not useful on some
+ architectures. Where possible, the program should be made
+ portable instead.
</p>
<p>
In the source package control file <file>.dsc</file>, this
- field may contain either the special value <tt>any</tt> or a
- list of architectures separated by spaces. If a list is given,
- it may include (or consist solely of) the special value
- <tt>all</tt>. In other words, in <file>.dsc</file> files
- unlike the <file>debian/control</file>, <tt>all</tt> may occur
- in combination with specific architectures. The
- <tt>Architecture</tt> field in the source package control file
- <file>.dsc</file> is generally constructed from the
- <tt>Architecture</tt> fields in the
- <file>debian/control</file> in the source package.
+ field may contain either the architecture
+ wildcard <tt>any</tt> or a list of architectures and
+ architecture wildcards separated by spaces. If a list is
+ given, it may include (or consist solely of) the special
+ value <tt>all</tt>. In other words, in <file>.dsc</file>
+ files unlike the <file>debian/control</file>, <tt>all</tt> may
+ occur in combination with specific architectures.
+ The <tt>Architecture</tt> field in the source package control
+ file <file>.dsc</file> is generally constructed from
+ the <tt>Architecture</tt> fields in
+ the <file>debian/control</file> in the source package.
</p>
<p>
@@ -2789,23 +2810,24 @@ Package: libc6
</p>
<p>
- Specifying a list of architectures indicates that the source
- will build an architecture-dependent package, and will only
- work correctly on the listed architectures. If the source
- package also builds at least one architecture-independent
- package, <tt>all</tt> will also be included in the list.
+ Specifying a list of architectures or architecture wildcards
+ indicates that the source will build an architecture-dependent
+ package, and will only work correctly on the listed or
+ matching architectures. If the source package also builds at
+ least one architecture-independent package, <tt>all</tt> will
+ also be included in the list.
</p>
<p>
In a <file>.changes</file> file, the <tt>Architecture</tt>
- field lists the architecture(s) of the package(s)
- currently being uploaded. This will be a list; if the
- source for the package is also being uploaded, the special
+ field lists the architecture(s) of the package(s) currently
+ being uploaded. This will be a list; if the source for the
+ package is also being uploaded, the special
entry <tt>source</tt> is also present. <tt>all</tt> will be
present if any architecture-independent packages are being
- uploaded. <tt>any</tt> may never occur in the
- <tt>Architecture</tt> field in the <file>.changes</file>
- file.
+ uploaded. Architecture wildcards such as <tt>any</tt> must
+ never occur in the <tt>Architecture</tt> field in
+ the <file>.changes</file> file.
</p>
<p>
@@ -4259,6 +4281,21 @@ Build-Depends: foo [!i386] | bar [!amd64]
bar</tt> on all other architectures.
</p>
+ <p>
+ All fields that specify build-time relationships may also be
+ restricted to a certain set of architectures using architecture
+ wildcards. The syntax for declaring such restrictions is the
+ same as declaring restrictions using a certain set of
+ architectures without architecture wildcards. For example:
+ <example compact="compact">
+Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
+ </example>
+ is equivalent to <tt>foo</tt> on architectures using the Linux
+ kernel and any cpu, <tt>bar</tt> on architectures using any
+ kernel and an i386 cpu, and <tt>baz</tt> on any architecture
+ using a kernel other than Linux.
+ </p>
+
<p>
Note that the binary package relationship fields such as
<tt>Depends</tt> appear in one of the binary package
@@ -7979,6 +8016,27 @@ done
</p>
</sect>
+ <sect id="arch-wildcard-spec">
+ <heading>Architecture Wildcards</heading>
+
+ <p>
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format <tt>any</tt> (which matches every
+ architecture), <tt><var>os</var></tt>-any, or
+ any-<tt><var>cpu</var></tt>. <footnote>
+ Internally, the package system normalizes the GNU triplets and
+ the Debian arches into Debian arch triplets (which are kind of
+ inverted GNU triplets), with the first component of the
+ triplet representing the libc and ABI in use, and then does
+ matching against those triplets. However, such triplets are
+ an internal implementation detail that should not be used by
+ packages directly. The libc and ABI portion is handled
+ internally by the package system based on the <var>os</var>
+ and <var>cpu</var>.
+ </footnote>
+ </p>
+ </sect>
+
<sect>
<heading>Daemons</heading>
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: