Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
Hi!
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).
> > + <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".
This was supposed to be an example to try to explain how this works,
and I mentioned it was not meant to be added directly, but it seems it
kind of ended up there somehow anyway. :)
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687#47>
> 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.
That triplet is how the code is handling the architecture internally,
and it was also just an example to help understand how it's working.
I don't think it makes much sense for people to use any-any-any
instead of just any.
> 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.
Ok, it's a bit more complicated just because it needs to adapt to the
current non-uniform architecture names. The triplets are the idealized
architecture names, although as they tend to be too long they get
a more reduced form depending on the wider of their usage. So if the
primary kfreebsd ports are glibc based they take over the namespace and
you just need to use kfreebsd-i386 to mean gnu-kfreebsd-i386, but if
someone would like to create a new port using a different abi then they
would need to use the full thing as in uclibc-kfreebsd-i386 for example.
The current best existing example is uclibc-linux-i386.
I think what might make all this easier to understand is seeing the
mapping table between Debian triplets and Debian architectures in
/usr/share/dpkg/triplettable, there you see how each of those get
expanded.
The only exception being that linux-<arch> is equivalent to <arch> (this
is done currently in the code and not derived from the table). It's
currently there for uniformity, and in case we'd like to do a slow
migration from <arch> to linux-<arch>, as I think as we start using
wildcards people might easily get confused with <arch> != any-<arch>. I
mentined this some time ago in -devel but people didn't seem enthusiastic
about such migration (even if it would be expected to be a slow
multi-year one).
Also not always linux-<arch> means gnu-linux-<cpu>, the clear example
is the armel case, being gnueabi-linux-arm. I don't think people should
generally be using the abi part of the triplet though. As it might
stop matching in some cases where you actually want a match (armel is
also a good example here). Also the abi is not fully exposed, for
example through the dpkg-architecture variables, mostly because I didn't
yet see the need, and people are already usually matching against the
wrong thing. That could change in the future, if it's shown to be
useful, though.
Hope this clarifies things a bit more!
regards,
guillem
Reply to: