Hi! On Thu, 2012-09-13 at 23:22:40 +0200, Johannes Schauer wrote: > 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?
While I guess in this specific case this might end up being correct, I don't think it's what was really meant. I'll describe what dpkg (supposedly) implements, which should match with what we discussed while drafting the multiarch specification, I'm not sure how apt implements this though. Dependency relationships w/o an arch qualifier apply by default to only the same architecture as the package declaring them, except for Conflicts/Breaks/Replaces which by default apply to arch:any. So, for examples: Package: a Architecture: arch-a Depends: d, e:any Conflict: b, c:arch-d would become, a:arch-a depends d:arch-a and e:any, conflicts b:any and c:arch-d. Or a more complex one: Package: w Architecture: arch-w Provides: x:arch-z Package: z Architecture: arch-z Depends: x About virtual packages, you should think about them either like pointers to real packages or like a new package instance generated per providing package. So given this, the architecture of a virtual package is (almost) always the one of the package providing it (if it was not arch-qualified of course). The only “exception” to all this is for self-provides, which extends the current semantics to treat a package set (a package sharing the same name) to allow them to be co-installed in case of M-A:same. Which is nothing more than adapting the current semantics to the general multiarch semantics. (There's a bug in dpkg which has allowed more lax handling of virtual packages and M-A:same relationships on remove and configure up to now, but I've fixed that and will be included in 1.16.9. And while code staring I've also found that arch-qualified dependecy relationships are broken on some conditions, which I've started fixing locally.) thanks, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
