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

[Guillem Jover <guillem@debian.org>]

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