Bug#530687: Support for architecture wildcards

[Russ Allbery <rra@debian.org>]

Here's a new wording proposal for this bug based on Manoj's previous patch
with some minor modifications from subsequent discussion.  I'm looking for
seconds; this material is rather overdue for making it into Policy.

diff --git a/policy.sgml b/policy.sgml
index ab8fedf..3c3d556 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2727,27 +2727,35 @@ 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">.
+		</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 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>.  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.
 	  </p>
 
 	  <p>
@@ -2789,6 +2797,27 @@ Package: libc6
 	  </p>
 
 	  <p>
+	    Specifying a list of architecture wildcards indicates that
+	    the source will build an architecture-dependent package on
+	    the union of the lists of architectures from the expansion
+	    of each specified architecture wildcard, and will only
+	    work correctly on the architectures in the union of the
+	    lists.<footnote>
+	      As mentioned in the footnote for specifying a list of
+	      architectures, this is for a minority of cases where the
+	      program is not portable.	It should not be used for most
+	      packages.	 Wildcards are not expanded into a list of known
+	      architectures before comparing to the build architecutre.
+	      Instead, the build architecture is matched against any
+	      wildcards and this package is built if any wildcard
+	      matches.
+	    </footnote>
+	    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
@@ -4259,6 +4288,23 @@ Build-Depends: foo [!i386] | bar [!amd64]
 	  source package section of the control file (which is the
 	  first section).
 	</p>
+        <p>
+          All fields that specify build-time relationships
+          (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+          <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>) 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
+          on any architecture using a kernel other than Linux.
+        </p>
       </sect>
 
       <sect id="binarydeps">
@@ -7956,6 +8002,29 @@ 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><var>os</var></tt>-any and
+          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 in use.  When matching two
+	    Debian arch triplets, whenever an <var>any</var> is found it
+	    matches with anything on the other side, like in:
+	  <example>
+  gnu-linux-i386     is matched by gnu-linux-any
+  gnu-kfreebsd-amd64 is matched by any-any-amd64
+          </example>
+          And, for example, <var>any</var> is normalized to
+          <var>any-any-any</var>.
+        </footnote>
+        </p>
+      </sect>
+
       <sect>
 	<heading>Daemons</heading>
 

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>