Further fixes to the architecture wildcard patch

Based on feedback from Kurt Roeckx.  Be explicit about what happens with
*.dsc and *.changes files, reorder the discussion somewhat, and remove
some duplicate text.

diff --git a/policy.sgml b/policy.sgml
index 4620b2e2d89d5dfe4c470a1a61975391d220f391..338ac7cfd0aaf89f91617412cd55f7f8dad40cea 100644 (file)
--- a/policy.sgml
+++ b/policy.sgml
@@ -2758,6 +2758,23 @@ Package: libc6
            portable instead.
          </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>
+             Use of architecture wildcards other than <tt>all</tt> is for
+             a minority of cases where the program is not portable and
+             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>
+         </p>
+
          <p>
            In the source package control file <file>.dsc</file>, this
            field may contain either the special value <tt>any</tt> or a
@@ -2789,43 +2806,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.
-         </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>
-             Use of architecture wildcards other than <tt>all</tt> is for
-             a minority of cases where the program is not portable and
-             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.
+           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> may
+           never occur in the <tt>Architecture</tt> field in
+           the <file>.changes</file> file.
          </p>
 
          <p>
@@ -4279,23 +4277,12 @@ Build-Depends: foo [!i386] | bar [!amd64]
          bar</tt> on all other architectures.
        </p>
 
-       <p>
-         Note that the binary package relationship fields such as
-         <tt>Depends</tt> appear in one of the binary package
-         sections of the control file, whereas the build-time
-         relationships such as <tt>Build-Depends</tt> appear in the
-         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:
+         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>
@@ -4304,6 +4291,15 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-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
+         sections of the control file, whereas the build-time
+         relationships such as <tt>Build-Depends</tt> appear in the
+         source package section of the control file (which is the
+         first section).
+       </p>
       </sect>
 
       <sect id="binarydeps">