Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
Manoj Srivastava <srivasta@debian.org> writes:
> Support for architecture wildcards has been added to dpkg-1.13.13. This
> patch, based on a proposal from Andres Mejia, provides policy on how
> architecture wildcards should be used for other tools such as sbuild and
> pbuilder. This patch has tracked and incorporated suggestions embedded
> the discussion of the proposal. It also brings policy up to speed and in
> line with dpkg-dev which appears to generate an Architecture line that
> includes both architectures and special values like "all".
> @@ -2737,15 +2742,16 @@ Package: libc6
> <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 either the special value
> + <tt>any</tt>, or the special value <tt>all</tt>, or a list of
> + specific and wildcard architectures separated by
> + spaces. If the special <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>
This removes the restriction that if all occurs, it must be the whole
value of the field. I'm fairly sure this is wrong in this section, which
is specifically talking about debian/control. That restriction is still
in place for debian/control; the change was only in other contexts, and I
think I already updated Policy for this change in the other contexts.
Also, a few grammatical nit-picks:
This uses "either" with more than two alternatives, which reads strangely
to me. It also repeats the word or before the alternatives. I would
instead say:
this field may contain the special value <tt>any</tt>, the special
value <tt>all</tt>, or a list of specific and wildcard architectures
separated by spaces.
In the sentence after this, the word "value" is missing in front of
<tt>any</tt>.
> + <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. Also note that the
> + wildcards are not expanded then compared, they are simply
> + matched. </footnote> If the source package also builds at
> + least one architecture-independent package, <tt>all</tt>
> + will also be included in the list.
> + </p>
It took me a bit to figure out what the last sentence of this footnote
meant. I think what you're getting at is that wildcards will match any
architecture, even completely unknown ones? I think we should try to find
a clearer phrasing, although I'm blanking at the moment. Maybe something
like:
Wildcards are not expanded into a list of known architectures before
comparing to the build architecutre. Instead, the build architecture
is matched against wildcards and this package is built if the wildcard
matches.
The distinction is very subtle, though, and I'm not sure I entirely
understand the implication.
> + <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:
> + <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
> + architectures using any kernel not being Linux and any cpu.
> + </p>
> </sect>
For the last example, just "<tt>baz</tt> on any architecture using a
kernel other than Linux" seems clearer to me, although not as literal of a
translation of the expression.
> + <sect id="arch-wildcard-spec">
> + <heading>Architecture Wildcards</heading>
> +
> + <p>
> + A package may specify an architecture wildcard. Architecture
> + wildcards are in the format <tt><var>os</var></tt>-any and
> + 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). So when matching two Debian arch triplets, whenever an
> + <var>any</var> is found it matches with anything on the other side,
> + like in:
> + <example>
> + gnu-linux-i386 == gnu-linux-any
> + gnu-kfreebsd-amd64 == any-any-amd64
> + </example>
> + And for example <var>any</var> is normalized to <var>any-any-any</var>.
> + </footnote>
> + </p>
> + </sect>
> +
I agree with the comment that == is probably better written as "matches".
The footnote introduces a triplet without saying anything about how the
first component of that triplet is derived, which I think makes it a bit
confusing. Can we say something here about how we get the full triplet?
I think what happens is that the kernel value turns into the first two
components of the triplet (linux always becomes gnu-linux), but I could be
wrong and it could be that linux means any-linux.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: