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.
------------------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part
