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

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


up to version 3.1, dose3 limited Conflicts of a package A to the
architecture of A. Bug#685171 addressed this issue, and as a result,
dose3 now adds conflicts for every architecture. Now, if A conflicts
with B, it conflicts with B in all its architectures.

Unfortunately, this behavior breaks the following class of packages:

Packages which are M-A: Same and provide a virtual package with which
they also conflict.

An example for such a package is linux-libc-dev. It is M-A: Same and

Replaces: linux-kernel-headers
Provides: linux-kernel-headers
Conflicts: linux-kernel-headers

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.

Example on an i386/amd64 system:

linux-libc-dev:amd64 provides linux-kernel-headers:amd64 and conflicts
with linux-kernel-headers:amd64 and linux-kernel-headers:i386.

linux-libc-dev:i386 provides linux-kernel-headers:i386 and conflicts
with linux-kernel-headers:amd64 and linux-kernel-headers:i386.

If linux-libc-dev:amd64 is installed, one can not install
linux-libc-dev:i386 anymore even though linux-libc-dev is M-A: Same.

The reason is, that linux-libc-dev:amd64 provides
linux-kernel-headers:amd64 with which linux-libc-dev:i386 conflicts.
Also, linux-libc-dev:i386 provides linux-kernel-headers:i386 with which
linux-libc-dev:amd64 conflicts.

The dilemma is solved by having all packages A that provide as well as
conflict with a package B and are also M-A: Same only conflict with B of
their own architecture and NOT all architectures.

This conclusion doesnt seem obvious to me and I didnt find it written
down somewhere.

So my question: is the following conclusion correct

> If a package A:$arch conflicts with a package B, then A:$arch
> conflicts with package B in all architectures EXCEPT if A is M-A: Same
> AND A also provides B. In this case, A:$arch only conflicts with
> B:$arch and NOT with B in all its architectures as it would be the
> default.

And if it is correct, should it be written down somewhere?

Also, if it is correct, is there a more general rule?

And are there more rules that are similar to this one?

This rule is for Provides but what about Replaces?

cheers, josch

Reply to: