Re: "Please drop perl dependency" bugs
On Fri, Nov 12, 2010 at 05:13:02PM -0500, David Golden wrote:
> 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.)
Thanks for joining in, David.
However, I think it's time to move most of this discussion to the
perl5-porters list, so I'm going to send a separate message there as a
followup to Florian's. I'll briefly respond here as well, though,
concentrating on the Debian specific issues.
> 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.
Yes, I believe this has always been the main worry and I sympathize.
I have some ideas about reducing the likelihood of invalid bugs and
standardizing things between distributions. I think this discussion
belongs on the perl5-porters list so I'll skip it here.
> 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.
I don't think this is a showstopper for the official Debian packages of
CPAN modules. Any missing dependencies should usually show up in the
packaging process when the tests are run in a clean chroot with only
the listed dependencies installed. The rest are just bugs that will be
fixed when they are noticed.
Any unofficial automatically generated debianizations of the CPAN modules
could still depend on the full perl package, of course.
> 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.
I'm not pushing for separating the dual life modules because I think
they are more optional than the others. The main benefit I see would be
that they could be maintained and updated more efficiently as separate
packages inside Debian.
Anyway, I think I agree with you here: before splitting out a package we
should do a feasibility study to determine how many packages actually
need it, and balance the installation size savings and the maintenance
efficiency against the added complexity.
> 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.
As in #1, I'll get to this in a separate message on the perl5-porters list.
> 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.
Unfortunately I don't think this is a realistic option for us. It's not
about just the critical parts of the Debian infrastructure: currently all
the 30000 packages in Debian are allowed to rely on /usr/bin/perl being
always present and working, including during system upgrades.
While most of those packages probably don't really need it, I
don't think there's a reliable way of even finding out which do short
of breaking them first.
Further, even if we did find out which packages would need to be changed
and managed to convince everybody of the necessity of the change, the
transition would most probably take several years [1] and result in
perl taken out of the base system completely (which in itself would IMO
actually be a good thing).
Anyway, I don't think this is going to happen.
> I hope you find these comments constructive. I've not seen the
> historical debate, so forgive me if I'm covering old ground.
Many thanks! I appreciate your comments and certainly found them
constructive. I hope my responses both here and on p5p come across in
the same manner.
[1] The infamous /usr/doc -> /usr/share/doc transition actually took nine
years; see http://bugs.debian.org/322762
--
Niko Tyni ntyni@debian.org
Reply to: