Re: architecture-specific dependencies on virtual packages

[David Kalnischkies <kalnischkies@gmail.com>]

On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> David Kalnischkies wrote:
>> while playing around with the APT code regarding architecture-specific
>> dependencies I stumbled over the handling of Provides in that context:
>>
>> Package: pkga
>> Status: install ok installed
>> Architecture: i386
>> Provides: foo
>>
>> Package pkgb
>> Architecture: amd64
>> Conflicts: foo:amd64
>
> 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.


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.

(In the given example, APT will see an unsatisfied dependency
 as it handles the provides architecture-dependent.)


 Best regards

 David Kalnischkies