I have seen this before, but I saw it the other day, and was just curious.
Why is aptitude so eager to uninstall packages instead of simply opting to
install a supporting package rather than upgrade it? I was upgrading
libssl1.0.0 the other day as a result of a security finding, and did the
whack-a-mole package upgrade, e.g. aptitude install libssl1.0.0. As a
result, it gave me the following packages have unmet dependencies. and
offered to uninstall several packages (like libssl-dev). Why would it do
this by default rather than just upgrading it? Here is an example from my
workstation:
# aptitude install libssl1.0.0
The following packages will be upgraded:
libssl1.0.0 libssl1.0.0:i386
2 packages upgraded, 0 newly installed, 0 to remove and 494 not upgraded.
Need to get 2,523 kB of archives. After unpacking 9,216 B will be used.
The following packages have unmet dependencies:
libssl-dev : Depends: libssl1.0.0 (= 1.0.1g-3) but 1.0.1g-4 is to be
installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) libssl-dev
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Upgrade the following packages:
1) libssl-dev [1.0.1g-3 (now) - 1.0.1g-4 (unstable)]
Accept this solution? [Y/n/q/?]
It would seem more logical to go ahead and upgrade the -dev package. And on
the servers at work, as I recall, one of the things it wanted to uninstall
was php5.
Why not just upgrade packages that fail dependencies if possible? I'm not
even suggesting installation of a bunch of new packages, but it seems to me
that it is a pretty straight-line conclusion that if the package needs to
be upgraded, and the -dev package is installed, then it's going to need to
be upgraded too.
Thoughts?
--b
