Re: "Please drop perl dependency" bugs

[David Golden <xdaveg@gmail.com>]

Hello.  I've just joined this list in response to a request on #p5p
for participation in this discussion.  For context, I am one of the
perl 5 porters and a co-maintainer for significant chunks of the Perl
module-installation toolchain.  (I am DAGOLDEN on CPAN for those who
might not know me.)

I have skimmed the recent threads, and have a few thoughts about the idea.

1) One problem with shipping a non-standard perl as /usr/bin/perl
(i.e. without some core libraries) is that you increase the likelihood
of bug reports to the perl upstream, which then have to be bounced
back to Debian.  This is a waste of time for both Debian Perl
maintainers and Perl 5 porters and inconveniences users who see
/usr/bin/perl and may assume they have a full perl install only to
find out they don't when things fail to work.  Some things might work
and some things might not, depending on which modules were involved.

2) Many CPAN module authors do not declare "core module" dependencies.
 They assume that if Perl 5.8 or 5.10 is installed, that all of the
core modules of that release are available.  By removing core modules,
it makes the CPAN module packaging process more complex if
dependencies have to be heuristically determined.  Alternatively, you
could have every packaged CPAN module depend on the full perl package,
but that seems like it would somewhat defeats the point of shipping a
minimal perl as the first CPAN package to be installed pulls in the
full perl anyway.

3) There is no clear guiding rule you can use to strip out modules
from the core.  Many of the 'dual-life' modules are dual-life because
they need to evolve faster than Perl historically has evolved in order
to fix bugs at an acceptable pace.  They are not "optional" simply
because they are *also* available through CPAN.  If anything, the
trend is towards *more* dual-life modules, as it allows modules to get
more testing before being included in the perl core and it allows
updated modules to be installed on older Perls. You can't use the
existence of modules on CPAN as a guide for what would need to be
removed.  It would have to be done on a case by case basis.

4) Many of the Perl 5 porters generally agree that it would be nice to
make more of the core optional and some efforts have started in that
direction.  (E.g. the clearer distinction between core-upstream and
CPAN-upstream).  However, shipping a limited set of perl libraries as
part of a major distribution would still violate the expectations of
most end-users, as per #1 above.

5) I see no problem with shipping a very minimal perl with Debian if
it were to be named something other than /usr/bin/perl.  For example,
if it were /usr/bin/perl-minimal or something, that would avoid
scripts with "#!/usr/bin/perl" or someone running "perl" at the
command line from executing a perl with a non-standard set of
libraries.  That would require any critical Debian infrastructure to
be re-written to use /usr/bin/perl-minimal, of course, but that's a
one-time cost, instead of the ongoing costs of #1 above.

I hope you find these comments constructive.  I've not seen the
historical debate, so forgive me if I'm covering old ground.

Regards,
David Golden