Re: architecture-specific dependencies on virtual packages
David Kalnischkies wrote:
> On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <email@example.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
should only be satisfied by a package from another architecture with
if package b also has Multi-Arch: foreign.
This might seem to imply that it would be useful to have an escape
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
Does that make sense? Can you help me connect the dots and see how
this relates to the question about Conflicts from before?