Perl related upgrade problems woody -> sarge
[directed to debian-release, debian-perl, and the filed bugs and their
This mail should give an overview for a problem with woody->sarge upgrades
reported multiple times.
All errors are mine and im seeking for comments ;)
On woody->sarge upgrades, sometimes maintainer scripts fail with the
Can't locate File/Basename.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl .) at /usr/sbin/install-docs line 17.
BEGIN failed--compilation aborted at /usr/sbin/install-docs line 17.
Filed as bugs #278495 and #279232.
I had a hard time reproducing it. I'm not sure yet, but a good trigger seems
to use aptitude (I usually take the one from sarge by upgrading there,
didn't tested it with the one from woody yet) and do the upgrade in interactive
mode, not by calling aptitude dist-upgrade. I wasn't able yet to reproduce it
either with apt-get dist-upgrade or aptitude dist-upgrade, only in interactive
mode. Seems that the install order produced by the dist-upgrade algorithms
usually avoids the problem. @submitters: do you remember how you did the
perl-modules is unusable when a new version with a different upstream version
is unpacked before perl with the corresponding upstream version. This is because
the modules rest in directories which contain the upstream version but the
search path for modules depends on the version of perl installed, not
Unpacking the new perl-modules before the new perl is allowed since it
"only" depends on perl (>= <upstream-version>) and this only needs to be
satisfied at configure time, not at unpacking.
- perl-modules pre-depend on perl. It isn't really sure if this doesn't
introduce other problems...
- change directory names in perl-modules. This would be a big change
to the upstream system and may introduce problems for people that
want to have more than one perl version installed.
- Let perl-modules define @INC. I doubt that this is possible and would
only work for non-binary perl modules.
- Work around the problem by changing install-docs so that it works without
File::Basename. This is easy, but it doesn't solve the real problem and
other programs called from maintainer scripts could be affected, too
(although there is no known example currently). It only solves the problem
if doc-base is updated before perl which would probaly require a pre-depends
- Tell people to update perl first. I don't know if this works, this would
require further testing. And why we have dist-upgrade in the first place
when people can't use it :(
- Tell people to ignore the error and just let them run apt-get -f install
after it occured which IME always worked well. If it really only happens
when using aptitude interactively this may even be acceptable, but should
nevertheless our last ressort if all other solutions turn out to be
Frank Lichtenheld <email@example.com>