[Aptitude-devel] Bug#775332: Bug#775332: Bug#775332: aptitude: Package conflicts are reported incorrectly

[David Kalnischkies]

On Wed, Jan 14, 2015 at 11:54:48AM +0100, Axel Beckert wrote:
> Keith Edmunds wrote:
> > I didn't expect it to list a conflict with spamassassin twice, nor did I
> > expect it to conflict with itself.

There are actually valid situations for both, the later is e.g.
explicitly allowed by debian-policy as a to be ignored self-conflict,
but takes effect on packages providing this name…


> The interactive text mode interface (TUI) shows why this happens:
> 
>   --\ Conflicts (3)
>     --\ spamassassin (< 2.30-2)
>     --\ spamassassin (< 2.30-2)
>     --\ spamc
> p    400  spamc:i386 3.3.2-5+deb7u2  0  136 kB
> p    990  spamc:i386 3.4.0-5         0  150 kB
> 
> The shown conflict is an implicit one: spamc has no Multiarch header,
> which implies "Multiarch: none" which again implies that it can't be
> installed together with spamc from another architecture.
> 
> Aptitude seems to show these implicit conflicts like explicit ones. If
> this is a good or bad thing is probably debatable.

(Indeed. Note that apt-cache does both: It doesn't show them in 'show',
while it does in 'depends'. It all heavily depends on what is expected
and both can be valid.)


> The duplicated spamassassin conflict can be explained that way, too:
> It probably duplicated it for each architecture, but doesn't show the
> architecture at that point.

That is in fact the correct explanation as it is how libapt is
translating multi-arch into the previously known single-arch.
This way our 'old' tools kept working without major changes.


> IMHO the output of aptitude in your case should have been similar to
> this:
> 
> Package: spamc                           
> State: not installed
> Version: 3.4.0-5
> Priority: optional
> Section: mail
> Maintainer: Noah Meyerhans <noahm at debian.org>
> Architecture: amd64
> Uncompressed Size: 186 k
> Depends: libc6 (>= 2.14), libssl1.0.0 (>= 1.0.0), zlib1g (>= 1:1.1.4)
> Suggests: spamassassin
> Conflicts: spamassassin (< 2.30-2) [amd64], spamassassin (< 2.30-2) [i386], spamc [i386]

This should be spamc:i386 and similar as this is the way architecture-
dependent dependencies are specified. In code, its probably something
along the lines of changing .Name() to .FullName(true).

Note that architecture-dependent dependencies are a thing now, so you
probably have to solve this either way, regardless of how you resolve
this one (assuming its a problem, I haven't checked).


> Maybe a specific marker for shown implicit conflicts due to multiarch
> wouldn't be a bad idea either.

Note that a dependency iterator has the method IsMultiArchImplicit() to
check if they are implicit or not in case you want to handle them
differently (and note that this also effects breaks and replaces).
btw: Provides can be implicit, too (see M-A: foreign).


Best regards

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20150114/685dd547/attachment.sig>