Bug#575308: perl: needs itself to build due to debian/dynaloader-config patch

[Niko Tyni]

Package: perl
Version: 5.10.1-5
Severity: important

While fiddling with 5.12.0-RC0 packaging, I ran into an unexpected
side effect of the debian/dynaloader-config patch [1] introduced in
5.10.1-5. The patch hardcodes a few Config variables in Dynaloader (in the
perl-base package) to avoid loading Config_heavy.pl (in the perl package.)

The 5.12.0-RC0 failure is

 ./miniperl -Ilib pod/pod2html.PL
 Extracting pod2html (with variable substitutions)
 Can't locate Config_heavy.pl in @INC (@INC contains: lib .) at lib/Config.pm line 70.
 make: *** [pod/pod2html] Error 2

It turns out that pod2html.PL (and others) does something like

 use Config;
 use Cwd;
 chdir "..";
 print $Config{startperl}, "\n";

which indirectly (and probably by accident) relies on the 'use Cwd'
line loading in Config_heavy.pl through DynaLoader.

This doesn't happen when our patch is applied, and after the chdir()
call Config_heavy.pl can't be found anymore.

The only reason the 5.10.1 packages currently build is that they
find Config_heavy.pl in @INC, namely /usr/lib/perl/5.10. This is
obviously not a good thing and breaks bootstrapping. 

I'm filing this at 'important' as we're effectively missing a build
dependency on perl (>= ${Upstream-Version}) or something like that.

Options include:

- moving Config_heavy.pl into perl-base and removing the upstream divergence

- patching DynaLoader to first try loading Config_heavy.pl and fall
  back to the hardcoded values on failure

- patching pod/pod*.PL to somehow load Config_heavy.pl before chdir()

The first two seem better choices than the third one, and I'm undecided
on which of the two is the correct solution. For some reason, I
thought including Config_heavy.pl would pull in a shared plugin object
(like Config.so) too, but this doesn't actually seem to be the case.

The question is whether the memory footprint of Config_heavy.pl is big
enough to justify the upstream divergence; saving 37k of disk space
(12k when compressed) doesn't seem as relevant even when thinking from
the d-i POV.

Also, as usual, once Config_heavy.pl gets in the Essential set, it
can't really be ever removed even if it gets heavier later. (This is an
argument for the second solution on the list because the first one is
irrevocable.)

I'd be glad to hear opinions from others.

[1] http://patch-tracker.debian.org/patch/series/view/perl/5.10.1-11/debian/dynaloader-config.diff 
-- 
Niko Tyni   ntyni at debian.org