Re: Perl related upgrade problems woody -> sarge
On Sat, Nov 20, 2004 at 03:11:34AM +0100, Frank Lichtenheld wrote:
>This mail should give an overview for a problem with woody->sarge upgrades
>reported multiple times.
>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.
>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.
>- perl-modules pre-depend on perl. It isn't really sure if this doesn't
> introduce other problems...
This doesn't really help you much, since the perl binary (which defines
@INC) is in perl-base.
Even having perl-modules and perl pre-depend on perl-base doesn't
necessarily fix the problem since while that would ensure that perl-base
was upgraded before either of those modules, there's no guarantee that
other packages wouldn't be pre-configured/configured between perl-base
and perl, perl-modules.
>- 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.
Moreover it takes the issue of a failing module load from being "not
found" (which may be trapped with eval{} such as debconf does) to a SEGV
or worse for binary modules.
>- Let perl-modules define @INC. I doubt that this is possible and would
> only work for non-binary perl modules.
@INC is hard-coded into /usr/bin/perl.
>- 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 :(
The fundamental problem here is that packages which use install-docs in
maintainer scripts don't depend on doc-base (since execution is
typically conditional), and hence don't necessarily depend on perl, nor
indirectly perl-modules or perl-base. For this reason it is possible
that install-docs will be called from a maintainer script while
perl-base+perl+perl-modules are in an inconsistent state.
Given that possibility, the solution for the future is to modify
install-docs to use only essential packages. Providing replacement code
for File::Basename (install-docs appears to use basename and dirname) is
pretty trivial.
For this upgrade, the only dependency changes which will actually
correct the problem are adding "Depends: perl" to any packages which
use install-docs in the postinst... probably not a reasonable solution.
Release notes instructing users with doc-base installed to "apt-get
install doc-base" prior to "apt-get dist-upgrade" may be a possibility.
--bod
Reply to: