[ Re-posting this as APT bug report, to keep track of it. The original
  version is at https://lists.debian.org/deity/2012/09/msg00088.html ,
  the thread with further discussion (and in particular the POV of one
  of the Policy Editors) at
https://lists.debian.org/deity/2012/09/msg00088.html ]

Executive summary: it seems that APT treats differently self-conflicts
for "Multi-Arch: same" packages, depending on whether the conflicts
happen on "real" or "virtual" package names. Conflicts on virtual
package names are ignored, whereas conflicts on real package names are
not.

Early discussions with -policy people seem to hint at a desired behavior
where "M-A: same" packages should be co-installable across different
architectures, ignoring self-conflicts, no matter if the conflicts
happen via real or virtual package names.

Cheers.
[…]

[…]

I could use double checking about the correctness of current APT's
behavior. From how Russ put it above, it shouldn't matter whether the
conflict is via a virtual package name or via a real package name:
self-conflicts across architecture boundaries should be ignored for M-A:
same packages.

According to the attached tests (which are courtesy of Pietro Abate), it
seems that APT does ignore self-conflict across arch boundaries when
they are via virtual packages (test 1), but it doesn't ignore them when
they are via real packages (test 2).


Looking on a random "desktop-like" laptop machine with various suites,
we've found ~200 packages which declare self-conflicts on their real
names (probably due to historical package renaming, that have remained
around). None of them is M-A: same, so the above alleged APT issue is
only theoretical at this point. But it might become real with the
increasing popularity of multiarch-ed packages in the Debian archive.


Cheers.

I made a patch for this already as I agree with Russ (and dpkg) here
even though I have a hard time comeing up with a good example why.
Attached (this time I made sure it really is…) and planed for 0.9.7.6.

It painfully shows that I made a mistake in not keeping track of the
types of a dependency (aka: explicit/implicit against all archs/one arch)
I guess I have to correct this for Jessie …

Anyway:
All APT front-ends need to be checked though as the dependency itself
exists, so if they check dependencies themselves they need to be told
to ignore them, too. As you can see in the patch libapt provides a method
for that, but the method is relatively new and the previous check for self-
conflicts so simple that it could easily be done on your own.
(There is a similar one for Provides, which isn't that trivial in M-A either,
 so we might want to check for this, too)

There shouldn't be that many clients implementing their own dependency
checking though - likely at most those with own solver implementations.
Hence cc'ing the aptitude deities so they can have an early look at that.


Best regards

David Kalnischkies

On 27 September 2012 01:26, David Kalnischkies <kalnischkies+debian@gmail.com> wrote:

Thanks.  Aptitude is indeed affected by this.

With patched apt installing on the command line is ok (unless there
are other conflicts).  The curses interface incorrectly infers that
the self-conflicts are broken for real and real-provider:

The following packages conflict with real and will be broken by
its installation:

  * real:amd64 conflicts with real

That much is superficial, to do with src/generic/apt/infer_reason.cc
(infer_reverse_breakage) or (is_simple_self_conflict).  The program
will actually proceed with installing real, but not real-provider, as
long as there are no other conflicts.

With real-provider the conflict is picked up elsewhere as actually
breaking the package.  This prevents installation and invokes the
problem resolver which likes to remove one of the packages.  It is at
least a few days before I have time to look at this further.

Regards