M-A: Same package A providing and conflicting with package B
Hi,
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
also:
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: