[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
following error:
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
  again :(

- 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
  uglier :/

Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/

Reply to: