Jonathan Nieder <jrnie...@gmail.com> writes: > Johannes Schauer wrote:
>> As I learned, the above means, that there must be only one package >> providing linux-kernel-headers. >> The problem is, that with linux-libc-dev conflicting with >> linux-kernel-headers of all arches, linux-libc-dev is not >> co-installable with itself anymore even though it is M-A: Same. > That does sound like a bug. The intuitive behavior when foo both > Provides and Conflicts with bar would be for the Conflicts to only > apply to other packages. Indeed. This particular combination of package metadata has a specific meaning defined in Policy 7.4: A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature. So you need to specifically recognize the case of Conflicts naming the package itself or a virtual package that this package provides, and in that case the Conflicts should not be applied to that package for installability determination. None of this language has, as yet, been updated for multiarch, but I think it makes logical sense for a M-A: same package to be coinstallable even if it Conflicts with its own package name or a virtual package it Provides, by extension from the intention of this construct without multiarch. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/877grx8pys....@windlord.stanford.edu