Coming back to an old patch... On Sun, Oct 4, 2009 at 23:42:21 -0500, Manoj Srivastava wrote: > diff --git a/policy.sgml b/policy.sgml > index 0bf1001..45d6643 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -2726,7 +2726,12 @@ Package: libc6 > values: > <list> > <item>A unique single word identifying a Debian machine > - architecture as described in <ref id="arch-spec">. > + 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><tt>any</tt>, which indicates a package available > @@ -2739,13 +2744,14 @@ Package: libc6 > 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. > + specific and wildcard architectures separated by > + spaces. If the special value <tt>any</tt> appears, it 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> Same comment as Russ for this hunk. > @@ -2786,6 +2792,24 @@ Package: libc6 > 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> As mentioned in the footnote for > + specifying a list of architectures, this is for a minority > + of cases where the program is not portable. Generally, it > + should not be used for new packages. Wildcards are not > + expanded into a list of known architectures before > + comparing to the build architecutre. Instead, the build Typo in "architecture" here. > + architecture is matched against wildcards and this package > + is built if the 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) With these two changes, seconded. Cheers, Julien
Attachment:
signature.asc
Description: Digital signature