[directed to debian-release, debian-perl, and the filed bugs and their submitters]
Hi. 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 ;) Problem: -------- 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. Reproduction: ------------- 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 upgrade? Analysis: --------- 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 perl-modules. 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. Solutions: ---------- - 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 <[EMAIL PROTECTED]> www: http://www.djpig.de/
