[Aptitude-devel] Bug#680822: aptitude fails to install libphonon-dev and phonon-backend-gstreamer

[Daniel Hartwig]

Control: tags -1 + moreinfo

Note that the initial report concerns sbuild calling apt-get to install
build-dependencies *indirectly* via a dummy-build-depends package.  The
second message is a test case, where aptitude is asked to *directly*
install specific packages.  These two modes are not equivalent; even if
both were using aptitude, the algorithms for each mode have subtle
differences.

Evgeni Golov <evgeni at debian.org> wrote:
> `aptitude install libphonon-dev phonon-backend-gstreamer` gives
>  The following packages have unmet dependencies:
>   phonon-backend-null : Conflicts: phonon-backend which is a virtual package.
>  The following actions will resolve these dependencies:
>
>       Keep the following packages at their current version:
>  1)     libphonon-dev [Not Installed]
>  2)     phonon-backend-null [Not Installed]
> (cowbuilder aborts here).
>
> However, `apt-get install libphonon-dev phonon-backend-gstreamer` works just
> fine.

The solution offered by aptitude is a valid resolution for the conflict.
For reference, subsequent offers are:
> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:
>
>      Keep the following packages at their current version:
> 1)     phonon-backend-gstreamer [Not Installed]           
>
>
>
> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:
>
>      Install the following packages:                      
> 1)     phonon [4:4.6.0.0-2 (unstable)]                    
>
>      Keep the following packages at their current version:
> 2)     phonon-backend-null [Not Installed]                

and this third one appears equivalent to how apt-get resolves the same
request.

Evgeni Golov <evgeni at debian.org> continues:
> Not sure why it tries phonon-backend-null at all (I requested
> phonon-backend-gstreamer), but I think this is because libphonon-dev 
> depends on
> phonon-backend-null | phonon
> and not
> phonon-backend-null | phonon-backend

Yes, that is why it tries to install -null.

Aptitude and it's dependency solver are intended mainly for interactive
use.  It is not a bug simply because aptitude may attempt to handle a
request with a different set of installs to apt-get, or initially
suggests a different resolution to a particular conflict than apt-get
would take.

Regarding the assignment to aptitude, Neil Williams
<codehelp at debian.org> wrote:
> … this does look
> like aptitude just not handling the Provides: Conflicts: correctly

1) Aptitude is asked to install libphonon-dev and
   phonon-backend-gstreamer.
2) There is no requirement to resolve dependencies of packages in any
   particular order.
3) Aptitude chooses to install phonon-backend-null to satisfy a
   dependency of libphonon-dev.
4) Aptitude does not consider that -null conflicts with itself via
   the virtual package phonon-backend.  Debian Policy requires that
   self-conflicts via virtual packages are ignored.
5) Aptitude does recognize that -null conflicts with -gstreamer via
   phonon-backend.  This conflict is reported.
6) Various solutions to (5) are offered.  The first few of these appear
   to be valid and the third covers the solutions that apt-get would
   find.

Can you be more precise about how aptitude has “not handled the
Provides: Conflicts: correctly”?  (4) and (5) seem correct to me.

> when
> other parsers are not affected.

The different behaviour of apt-get and aptitude is due to differences in
how they choose to satisfy dependencies and resolve conflicts that
arise.  This does not imply that either program is broken.

Regards