[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: M-A: Same package A providing and conflicting with package B

Jonathan Nieder <jrnieder@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: