On Thu, Jun 03, 2010 at 09:56:30AM -0700, Russ Allbery wrote:
> 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 (r...@debian.org)               <http://www.eyrie.org/~eagle/>

Seconded.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slanga...@ubuntu.com                                     vor...@debian.org



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100604005251.ga13...@dario.dodds.net

Reply via email to