[Aptitude-devel] Bug#809655: aptitude: harrowing upgrade for the perl transition

[Manuel A. Fernandez Montecelo]

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
fix it.


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