[Aptitude-devel] Bug#556881: aptitude: unable to install a package A that depends on B, if B Provides A and at the same time Conflicts/Breaks/Replaces A

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Fri Mar 18 12:49:52 UTC 2016


Control: retitle -1 aptitude: unable to install a package A that depends on B, if B Provides A and at the same time Conflicts/Breaks/Replaces A
Control: tags -1 + help

2009-11-18 00:20 Raphael Geissert:
>Package: apt
>Version: 0.7.23.1
>
>Hi,
>
>Given the following circumstances, apt fails to find a solution:
>
>8<--------------------------------->8
>Package: foo
>Depends: bar
>
>Package: bar
>Provides: foo
>Conflicts: foo
>Replaces: foo
>
># apt-get install foo
>Reading package lists... Done
>Building dependency tree
>Reading state information... Done
>Some packages could not be installed. This may mean that you have
>requested an impossible situation or if you are using the unstable
>distribution that some required packages have not yet been created
>or been moved out of Incoming.
>The following information may help to resolve the situation:
>
>The following packages have unmet dependencies:
>  foo: Depends: bar but it is not going to be installed
>E: Broken packages
>8<--------------------------------->8
>
>The obvious solution here is to simply install bar, and not foo.


2009-11-18 01:05 Raphael Geissert:
>retitle 556799 readahead is uninstallable with current dependencies resolvers
>block 556799 with 556869,556881
>tag 556799 confirmed
>thanks
>
>2009/11/17 Sven Joachim <svenjoac at gmx.de>:
>> Package: readahead-fedora
>> Version: 2:1.5.4-2
>> Severity: serious
>>
>> Thank you for providing a transitional readahead package, but there is a
>> little problem with it.  Namely, it is not actually installable:
>[...]
>> The solution is to version the "Conflicts: readahead", obviously.
>>
>
>Yes and no.
>
>Yes, because it is currently uninstallable because of a, IMO, a bug on
>the resolvers' side (but I plan to workaround it, don't worry) as
>there _is_ a solution.
>
>No, because the conflict is there to avoid installing readahead-fedora
>together with whatever other readahead implementation you may choose
>to install (say sreadahead, ureadahead, etc; they all provide
>'readahead').
>
>The current workaround on the users side is to install the *real*
>package, not the transitional one. That is, install readahead-fedora
>or upgrade from readahead, but don't install readahead.
>
>Cheers,
>-- 
>Raphael Geissert - Debian Developer
>www.debian.org - get.debian.net


2009-11-18 13:23 Daniel Burrows:
>  Personally, I think that assuming that "bar" should be installed
>without any more hints from the user is a bit of a stretch; they
>asked to install "foo", not "bar", and it can't be installed.  I don't
>know that aptitude should be trying to second-guess its command line
>here.
>
>  I do think that it would make sense for aptitude to print out a list
>of packages that C/P/R "foo".
>
>  Daniel


2009-11-18 15:25 Raphael Geissert:
>Hi Daniel,
>
>2009/11/18 Daniel Burrows <dburrows at debian.org>:
>>  Personally, I think that assuming that "bar" should be installed
>> without any more hints from the user is a bit of a stretch; they
>> asked to install "foo", not "bar", and it can't be installed.  I don't
>> know that aptitude should be trying to second-guess its command line
>> here.
>
>The thing is that bar provides "foo", satisfying the user request.
>
>>
>>  I do think that it would make sense for aptitude to print out a list
>> of packages that C/P/R "foo".
>>
>
>It would be great if aptitude does that, in case the outcome of this
>request is that such a package is still considered uninstallable and
>"broken".
>
>Cheers,
>-- 
>Raphael Geissert - Debian Developer
>www.debian.org - get.debian.net

Quoting the relevant messages from the report (including the reply to
Sven's, which is hidden in the BTS website for some reason).

As the reply from Sven, I think that perhaps Conflicts or other fields
should be versioned, but didn't think much about it.

In any case, it's still open in apt but maybe has been silently fixed.
aptitude relies on apt for the normal resolution, so if it's either
fixed or present in apt, it's still the same in aptitude for the normal
cases.

This should be easy to test using equivs.

Tagging +help in the case that there's some charitable soul wanting to
lend a hand.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>



More information about the Aptitude-devel mailing list