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 <svenj...@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 <dburr...@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.montez...@gmail.com>
