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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
