Re: architecture-specific dependencies on virtual packages

[David Kalnischkies <kalnischkies@gmail.com>]

On Fri, Jul 13, 2012 at 11:36 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> David Kalnischkies wrote:
>> As an example:
>> I highly doubt "phonon:amd64" with a dependency on "phonon-backend" will
>> work with "phonon-backend-vlc:armel" which provides "phonon-backend".
>>
>> If phonon-backend would be a normal package only phonon-backend:amd64
>> could satisfy the dependency, but just because it is virtual the
>> architecture is no longer important for dpkg. That sounds wrong.
>
> I agree here.  If I understand correctly, you are saying that it would
> be best if a dependency
>
>         Package: a
>         Depends: phonon-backend
>
> should only be satisfied by a package from another architecture with
>
>         Package: b
>         Provides: phonon-backend
>
> if package b also has Multi-Arch: foreign.

Yeap, that is what I would expect and it is what APT currently does.
This thread is a try to understand why dpkg does it differently.
aka: Valid reasons or just a bug?


> This might seem to imply that it would be useful to have an escape
> valve
>
>         Package: a
>         Depends: phonon-backend:any
>
> But I don't think so.  To know that phonon backends of all
> architectures satisfy the dependency, we need to know something about
> how the packages providing phonon-backend actually work, so it seems

We don't really need an "escape value" here. You have no chance to do that
for dependencies on 'real' packages, so why would we need it on virtual?
(beside that :any is already taken by M-A:allowed packages)


> most sensible to make this dependency only satisfiable by non-virtual
> packages.

I can't follow on that one as if you are referring to the example above
we suddenly have no dependencies left which could be satisfied by virtuals.
So you probably lost me somewhere.


> Does that make sense?  Can you help me connect the dots and see how
> this relates to the question about Conflicts from before?

Sorry, I tend to write confusing sentences at night
(Not that this would get any better in daylight…).

It's connected to Conflicts in the way that it effects all dependencies.
I just found it first with explicit architecture-specific Conflicts, but
in fact provides are never checked for an architecture, regardless of
dependency type and regardless of a explicitly mentioned architecture or not.


Best regards

David Kalnischkies