[Aptitude-devel] Bug#688863: non-uniform treatment of self-conflicts for real/virtual "M-A: same" packages

[Daniel Hartwig]

Control: clone 688863 -2
Control: reassign -2 aptitude 0.6.8.1-1

On 27 September 2012 01:26, David Kalnischkies
<kalnischkies+debian at gmail.com> wrote:
> On Wed, Sep 26, 2012 at 2:25 PM, Stefano Zacchiroli <zack at debian.org> wrote:
>> [ 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 ]

> 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.

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