perl-modules lucid->precise upgrade failure: debsums is noisy when Perl-related packages are inconsistent

[Thomas Bushnell, BSG]

Upgrading from lucid to precise finds a problem with the defoma invocation in the prerm of the libwmf0.2-7 package, when upgrading from 0.2.8.4-6.1ubuntu2 to 0.2.8.4-8.1ubuntu1, and with apt-get's invocation of debsums.

The error reported is this, from dpkg (via apt-get):

Can't locate File/Find.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/debsums line 10.
BEGIN failed--compilation aborted at /usr/bin/debsums line 10.

Likewise, the prerm in libwmf0.2-7 runs "defoma-app clean libwmf0.2-7", and gets this error:

Can't locate File/Copy.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/defoma-app line 7.
BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7.

At the time this runs, defoma version 0.11.10-4ubuntu1 is installed; 0.11.12ubuntu1 is the candidate but has not been fetched or installed. Note that this complies with libwmf0.2-7's defoma dependency (defoma (>= 0.11)).

Likewise, debsums version 2.0.48 is installed, with 2.0.49 as the candidate, but not yet fetched or installed.

Before the upgrade, the relevant perl files were found at /usr/share/perl/5.10.1/File/Copy.pm and /usr/share/perl/5.10.1/File/Find.pm, from perl-modules version 5.10.1-8ubuntu2.1.

At the time of the errors, however, perl-modules has been upgraded, and now version 5.14.2-5ubuntu1 is installed. Both File/Copy.pm and File/Find.pm are in their expected places at /usr/share/perl/5.14.2.

The root problem seems to be that perl-base and perl-modules are out of sync; perl-base is at version 5.10.1-8ubuntu2.1, with 5.14.2-5ubuntu1 as candidate, but not yet unpacked or installed.

It seems that perl-modules depends on "perl (>= 5.14.2-1)", which in turn depends on "perl-base (= 5.14.2-5ubuntu1)".

apt-get has correctly resolved these, and its invocation wishes to install both, but at the time of the error, it has unpacked and installed perl-modules, but has not yet done so for perl-base.

But alas, it does not know that they cannot be installed out-of-order. I think a Pre-Depends of some sort is necessary here, to guarantee that the modules (and perhaps some other things) are not upgraded before the interpreter itself is ready for them, since the package management system itself is dependent on perl.

[Colin Watson (cjwatson)]

As far as I've been able to determine, there's no way to resolve this by means of even something as strenuous as Pre-Depends, without causing other worse problems (e.g. Pre-Depends loops; perl-base and perl-modules have to be in sync, not merely in order). As documented in policy, a prerm may only assume the following:

  The package whose prerm is being called will be at least "Half-Installed". All package dependencies will at least be "Half-Installed" and will have previously been configured and not removed. If there was no error, all dependencies will at least be unpacked, but these actions may be called in various error states where dependencies are only "Half-Installed" due to a partial upgrade.

The libwmf0.2-7 situation is exactly what policy is warning about; the dependencies are only unpacked and not configured.

The strategy we're adopting when we find such upgrade bugs is to correct the package to conform to policy instead, to avoid prerms requiring configured dependencies; there is really no other workable solution as far as I've been able to determine, although I appreciate that it does initially seem as though it should be possible to fix it in perl (I've been down this road already). In some cases this can be achieved by causing them to require only Essential packages, which are required to always behave as if they were configured after they've been configured once; for instance, a Perl script can do this by relying only on those modules in perl-base.

In the case of libwmf0.2-7, however, defoma has mercifully been deprecated and is on its way out, so the fix is essentially just to stop using it. This had been done in Debian by the time I saw this upgrade failure, so I merged that change into precise. There was one last tweak required: when dpkg is upgrading a package and the prerm from the old version fails, it will fall back to trying the new version; so, in the knowledge that the old prerm was likely to fail, I added a no-op prerm to the new version of libwmf0.2-7 so that dpkg would fall back to that and thus succeed. I've tested that this is sufficient to get past that upgrade failure. This was bug 904901, so I'll leave that be and consider only debsums in this bug from this point onward.

The debsums failure is new to me; but in that case, it's being run out of band to some extent, and I think it would therefore be prudent of it to rely only on packages in the Essential set. We did something similar with doc-base. perl-base and perl-modules could then Conflict with versions of debsums before that fix.

[Thomas Bushnell, BSG (tbushnell)]

Thanks for looking at this Colin; I appreciate the eyes! It's in the depths of dark magic to me sometimes.

For this to work reliably in a cross-version lucid->precise upgrade, however, won't you need to push a new libwmf0.2-7 package in lucid that fixes its prerm?

[Colin Watson (cjwatson)]

On Thu, Jan 26, 2012 at 01:49:54AM -0000, Thomas Bushnell, BSG wrote:
> For this to work reliably in a cross-version lucid->precise upgrade,
> however, won't you need to push a new libwmf0.2-7 package in lucid that
> fixes its prerm?

No, because dpkg will fall back to the new prerm (i.e. the one in the
package it's upgrading to). This is a very useful get-out clause. It
does require libwmf0.2-7 in precise to ship a no-op prerm rather than no
prerm at all, which is a little surprising, but otherwise it works.

[Thomas Bushnell, BSG (tbushnell)]

Sounds great. Given the large number of packages using defoma, it might be worth a comprehensive scan across lucid to make sure the no-op prerm is in place for all of them.

[Colin Watson (cjwatson)]

Avoiding things like File::Find in debsums is rather difficult. There's another possibility: we could just have debsums bail out cleanly (with an error message) if File::Find can't be imported. apt will get round to running it again at a more convenient time anyway, and it will catch up with all the work it needs to do then.

The one wart is that debsums will have to exit 0 in this case to avoid breaking apt. That's unpleasant, but I think it's a necessary evil.

[Colin Watson (cjwatson)]

It occurs to me on analysis of apt that the debsums part of this cannot possibly cause an upgrade failure. The reason for this is that DPkg::Post-Invoke hooks are run in precisely three cases:

  1) waitpid for dpkg failed (i.e. some kind of programming error); return code from Post-Invoke is ignored
  2) dpkg exited with a non-zero wait status; return code from Post-Invoke is ignored
  3) every dpkg invocation in a complete apt run exited successfully

The mistake in my earlier analysis was that I believed that debsums might be run in the middle of an otherwise successful apt run. This is not so, both from code inspection and empirically. The only case in which a non-zero exit code from debsums can make the slightest difference to an upgrade is in case 3, and in that case it's running at the end of a successful apt run so can reasonably assume that apt left the perl packages in a sane state. Even if it fails there, the worst that happens is that it causes apt to exit non-zero after doing all its work; it's not going to convert a complete successful run into a partial failed run, which would be the real problem.

So, I think this is essentially cosmetic. It showed up as a problem in your original report because libwmf0.2-7's prerm had already failed, upon which apt attempted to run debsums as part of general cleanup, but it didn't actually make the situation any worse. If the libwmf0.2-7 problem hadn't been present, you wouldn't have seen a problem with debsums either.

I'll downgrade this to low and keep it open, because it might be worth changing debsums to catch these errors and add a clarifying note that it's probably due to Perl being mid-upgrade. However, based on the analysis above, I don't think we should muck around with debsums' exit code.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release