On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <jrnie...@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 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdgxyvbkdydxvdfskwowzfanlwmeqeer8to++h4nbr...@mail.gmail.com