Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Thu, 2010-06-03 at 00:06:39 +0200, Guillem Jover wrote:
> On Fri, 2009-10-02 at 13:28:30 -0700, Russ Allbery wrote:
> > Manoj Srivastava <srivasta@debian.org> writes:
> > > + <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.
>
> From a comment somewhere else I think you understand it now, but
> anyway just to make sure, it allows adding new architectures in dpkg
> w/o needing to recreate the source package from its internal
> representation where the wildcards are located (debian/control) to the
> external ones (.dsc, .changes, and those percolated to meta-indices,
> etc).
Actually I think it's me who didn't understand. :) I just rememebered
commenting about this in [0], so assumed it was the same. Anyway this
seems to be a mix of the original patch, and my comment, which do not
quite match together as they kind of contradict each other. Back then
it was a comment to try to correct the wording in the original patch
which was mentioning explicitly something that was not quite right. I
don't think this needs to be spelled out in policy either way, it's
just an implementation detail. The only thing that might make sense to
mention as rationale is why the wildcards don't get expanded from the
internal source representation to to the external ones, as mentioned
above.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687#47>
regards,
guillem
Reply to: