Needing perl to build perl

[Niko Tyni]

On Sat, Jan 28, 2012 at 05:37:35PM +0000, Dominic Hargreaves wrote:
 
> I spotted that although we don't use debhelper (I assumed that this was
> to avoid bootstrapping problems building perl with perl available - but
> maybe it's just that no-one's wanted to go through and modernise the rules
> file) we do use a few utilities from dpkg-dev written in perl:

It definitely has to do with bootstrapping, quoting Brendan in #556847:

> Note that one of the reasons why perl has a slightly eccentric rules
> file is so that the package is able to be built on a system without
> any perl installed.  This was to allow new ports to bootstrap and is
> the reason why ./perl.static is used in that file rather than
> /usr/bin/perl.  It is entirely possible that bit-rot has made this no
> longer work, but it is still a useful goal to retain.
> 
> See debian/checkperl, which is invoked for the install rule.

I believe the perl scripts in dpkg-dev are the primary cause for
the bit-rot.  However, I don't think we can hardcode things like
'./perl.static /usr/bin/dpkg-architecture' in debian/rules, because of:

- ABI skew when building a different major version than
  the one on the system: any XS modules that dpkg-architecture might
  load would not work with the perl we're building.

- we can't really know if /usr/bin/dpkg-architecture turns
  into a compiled binary or a python script in the next dpkg-dev version.

> debian/config.debian:
> - dpkg-architecture
> 
> debian/rules:
> - dpkg-parsechangelog
> - dpkg-gencontrol
> - dpkg-shlibdeps

> My question is, I suppose: is there any reason not to start using
> another perl script from dpkg-dev in the rules file, or should we be
> aspiring not to require perl to build perl?

I don't see how adding dpkg-buildflags would make the situation any worse
than it currently is, though ideas for improving this area would be welcome.
-- 
Niko Tyni   ntyni at debian.org