Re: architecture-specific dependencies on virtual packages

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

David Kalnischkies wrote:
> On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Conflicts with an architecture seem kind of like conflicts with a
>> version.  That would mean that that virtual packages wouldn't qualify.
>> Could that work well in practice?
>
> Probably hard to implement in APT, but I don't think it would help -
> or that it would be correct:
>
> If a dependency has no architecture attached we assume that the
> dependency is satisfiable only by a package from the same architecture
> as the package which has the dependency. So we already have
> architecture-specific dependencies, we just do not specific them explicitly.

I'm following so far.

> But dpkg doesn't check the architecture for provides, so any foreign package
> can provide a "service". This usually works as most "services" are binary-
> independent, but there are also quiet a few where this fails miserably.
>
> 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.

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
most sensible to make this dependency only satisfiable by non-virtual
packages.

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

Thanks,
Jonathan