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

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
>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.


Reply to: