Bug#560058: [buildd-tools-devel] Bug#560058: quinn-diff: should support architecture wildcards

[Andres Mejia <mcitadel@gmail.com>]

On Sat, Feb 13, 2010 at 5:58 AM, Philipp Kern <pkern@debian.org> wrote:
> Andres,
>
> On Wed, Feb 10, 2010 at 02:46:10AM -0500, Andres Mejia wrote:
>> The Dpkg::Arch function debarch_is() takes the first parameter as the
>> architecture and the second parameter as the alias (wildcard). So using an
>> alias of "any" will always match true, regardless of what architecture is set,
>> such as "s390". Also, trying to match "any" against "linux-any" will fail via
>> debarch_is(), since it won't recognize "linux-any" as an architecture. This is
>> the behavior you should expect.
>>
>> By the way, I'm attaching a patch against the dpkg-perl branch that fixes the
>> ordering of the parameters to debarch_is(). I've also optimized the
>> arch_equivalent() function when use_equivalence is set to true. Now all
>> aliases of "any" and "all" return true and skip running the Perl code
>> entirely. Setting the alias to "any" would always return true from
>> debarch_is() anyway, and debarch_is() doesn't recognize "all" as an alias,
>> though "all" should always return true as well.
>
> sadly I didn't have much time yet to think it through, but I should share
> my comments: I'm not entirely happy with the current state as the
> signature suggests that architectures could be passed into this function
> in an arbitrary order.  Could you update the signature and add some
> comment outlining how it works?
>
> As I understood it the order of the equivalence is currently inverse to
> what debarch_is expects (i.e. element out of list, current arch/any/all
> instead of current/any/all, alias/wildcard).  Now if I check this:
> is_equivalent("linux-any", "any") then linux-any is an element in the
> architecture list and this should yield true.  I guess that your patch
> now does this?  (I found the first paragraph a bit hard to understand.)
>
> is_equivalent("linux-any", "all") should also yield true as you state.
> However is_equivalent("amd64", "all") should of course yield false.
> So I'm not exactly sure (yet) how you see that all should always yield
> true.  :)
>
> Kind regards,
> Philipp Kern

OK. So in the dpkg-perl branch, the way arch_equivalent() is being
used is that it's being passed an element out of a list of
architectures and/or aliases as the 'arch1' argument, the architecture
from the Packages file or whatever was set with the '--architecture'
option as the 'arch2' argument, and a boolean value to indicate
whether to use or not use debarch_is() from Dpkg::Arch.

debarch_is() takes a valid architecture as it's first argument, and a
valid alias as it's second argument. This was one of the reasons for
the last patch, as debarch_is() was instead being passed an alias as
it's first argument, and an architecture as the second argument.

One of things to note is that you cannot call debarch_is("linux-any",
"any") as "linux-any" is not a valid architecture. Something like
debarch_is("<some valid arch>", "linux-any") would be ok however.

Now something like debarch_is("amd64", "all") would yield false since
"all" is not a valid alias. I was thinking packages that were
architecture indepedent ("all") were like packages that can be used in
"any" architecture, which is why I was saying that passing "all" as
the first argument to arch_equivalent() should always yield true. I
suppose we can assume the default behavior from debarch_is() instead,
which is to always yield false.

-- 
Regards,
Andres Mejia