[Aptitude-devel] Bug#809655: aptitude: harrowing upgrade for the perl transition
Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Wed Feb 17 12:24:01 GMT 2016
Control: tags -1 + moreinfo
2016-01-09 22:20 To Paul Wise:
>2016-01-05 18:53 Niko Tyni:
>>On Tue, Jan 05, 2016 at 04:45:56PM +0100, gregor herrmann wrote:
>>>On Sat, 02 Jan 2016 20:53:56 +0800, Paul Wise wrote:
>>>> I had a very harrowing upgrade for the perl transition. The first
>>>> upgrade managed to remove perl-base somehow and failed spectacularly.
>>>> The second and third upgrades also failed but less so and the fourth
>>>> upgrade succeeded. I was doing the upgrade in the aptitude console UI
>>>> and didn't (AFAIR) select the removal of perl-base.
>>>I've successfully updated perl 5.22 on 2 unstable machines with the
>>>aptitude TUI 2 weeks ago, but I can't remember how much I had to help
>>>aptitude (that was still during the binNMU phase).
>>>Today I updated 2 testing machines (disclaimer: raspbian, but I'm not
>>>aware of any difference in either aptitude or perl) to perl 5.22
>>>again with the aptitude TUI, and I watched closesly:
>>>- Both upgrades succeeded.
>>Thanks to Gregor for the testing, and to Paul for filing the bug.
>>I've glared at the src:perl control file but I can't find any obvious
>>error that could lead to this. The best candidate is that libperl5.22
>>and perl-modules-5.22 Replace: perl-base (<< 5.22.0~), but as they don't
>>conflict, that should AFAICS convey the intended policy 7.6.1. meaning
>>("Overwriting files in other packages") rather than 7.6.2. ("Replacing
>>whole packages, forcing their removal"). But maybe I'm missing something?
>>So: dear aptitude maintainers, your input would be very much appreciated.
>Looking at the logs, it seems that the main problem is when upgrading
>perl-base, it somehow gets in a "removed" state in the first attempt.
>(The failures in subsequent attempts are related to this, I think).
>This is not reflected in the log of aptitude, first is "upgrade" and
>after that is "install", because of being "removed" after the first
>attempt. Same from the apt log.
>dpkg log is the one showing that perl-base (v 5.20) was requested to be
>removed in fact (I guess that as part of an upgrade action), and
>complains about it because of rev-deps, but apt calls dpkg with --force
>(for some design reasons) so it takes the action anyway.
>Since the different programs invoked in the interim fail (see below),
>dpkg considers that the perl-base package is not-installed, causing the
>subsequent aptitude/apt to request to install it.
> /var/lib/dpkg/info/man-db.postinst: 22: /var/lib/dpkg/info/man-db.postinst: perl: not found
> /usr/share/debian-security-support/check-support-status.hook: 17: exec: /usr/share/debconf/frontend: not found
> dpkg: error: error executing hook 'if [ -x /usr/share/debian-security-support/check-support-status.hook ] ; then /usr/share/debian-security-support/check-support-status.hook ; fi', exit code 32512
> /usr/bin/etckeeper: 124: /usr/bin/etckeeper: perl: not found
>I believe that aptitude doesn't request the "removal" in any case, and
>relies on libapt for dealing with ordering and actual communication of
>actions with dpkg.
>I am not sure if the problem is that apt asks for "removal" instead of
>"upgrade", or that dpkg interprets "removal" instead of "upgrade", or
>that simply dpkg applies upgrades as "remove old version + install new
>version", and that the scripts above are unprepared to handle this
>situation. In most package upgrades I think that dpkg doesn't
>"remove+install", but maybe the mentioned "Replaces" or other details
>forced the decision to do it in that way by apt or dpkg.
>I will notify the different maintainers so they can take a look to this
>report and see if it's a known problem and discuss whether we can try to
(I hoped to be able to follow-up sooner and with more concrete details,
but other things got in the way, sorry).
I communicated the problem above to the maintainers of apt and dpkg a
few weeks ago. There seems to be some disagreement about which program
is not doing things correctly, but the problem was known and reported.
It's a bit surprising that nobody else reported this problem. Perhaps
the users are too used to the problems of aptitude resolving upgrades,
but since the results described here are unusual and perl is installed
in all Debian systems, I expected more feedback.
In any case, as I said in the previous e-mail, aptitude doesn't
communicate directly with dpkg nor decides the order of the actions, and
aptitude decided in the first iteration that the program should be
"upgraded" and not "removed + installed", so I don't think that we can
do much from this side.
So I am wondering if we should do as Paul said in the original report:
"If this bug report isn't useful, please close it."
It's not exactly useless, it's useful if only to learn about this
problem happening, but I really don't think that we can do much more
from aptitude's side.
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
More information about the Aptitude-devel