Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Thu, 2010-06-03 at 13:09:38 -0700, Russ Allbery wrote:
> Guillem Jover <guillem@debian.org> writes:
> > On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote:
>
> >> <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).
>
> Hm, really? It doesn't make a tremendous amount of sense to combine any
> and other wildcards, since it's duplicative, but is it actually rejected?
> I can put the restriction in the syntax if it is, but it doesn't seem like
> it should be strictly necessary.
Yes, dpkg-source will reject such package. The check has always been
there, it just never got relaxed when introducing the generic wildcard
support. This is the actual error when using as value for example
“any linux-any”:
dpkg-source: error: architecture any only allowed on its own (list for package fbset is `any')
regards,
guillem
Reply to: