On Thu, 2010-06-03 at 22:01 +0200, Guillem Jover wrote:
> Hi!
>
> On Thu, 2010-06-03 at 09:56:30 -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.
>
> Thanks!
>
> > 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
>
> “any” must also only appear by itself (that got lost from the previous
> text).
>
> > + 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>
>
> With that correction, seconded.
seconded.
Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Look afar and see the end from the beginning.
------------------------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part