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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20120913212240.GA27285@hoothoot
