Hi, David Kalnischkies wrote: > On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder <jrnie...@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 -- 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/20120713213608.GA31498@burratino