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

Re: "Please drop perl dependency" bugs



[Cc-ing perl5-porters@perl.org]

Hi. I'm yet another perl 5 porter having a couple of thoughts on this as
well.

Perl upstream is already at work on cutting down the perl core to remove
extraneous modules. We do want to make sure that the core release can
always bootstrap CPAN, but past that, we have a vague, informal goal of
being able to ship a "core-perl" with a super-minimal set of
libraries. If Debian and Ubuntu want this as well, we'd love help.

We don't fully know what that will all look like, but if others want to
do something like it as well, we'd rather we get them to help us do it
in some standard way.


Also, I think that a user installing the `perl' package should end up
with the full content of the perl 5 distribution available. Your current
plan seems already have that covered. That's good.


What's not entirely clear to me yet is what sort of space savings you're
looking for. Is it just dropping various modules, or are you also
planning to cut back on core features? I imagine there's some space to
be gained by providing a small perl without full unicode support,
avoiding to compile in lots of information from the unicode character
database.

I believe much of the infrastructure for that already exists for
miniperl, which is a perl without all the features that gets compiled
during perl's build process to later bootstrap the real perl with all
features.


However, the thought of having a /usr/bin/perl without all the
functionality included in a perl release doesn't seem very appealing to
me. For that reason I sympathise with David's suggestion of having a
/usr/bin/minimal-perl or /usr/bin/system-perl or whatever instead, and
have the base system tools use that instead of a full perl in
/usr/bin/perl.

That wouldn't just avoid confusion, but also have various other
benefits.

  - It would have to have an @INC path separate from the real perl's
    @INC. With that, users installing or upgrading modules via CPAN
    can't break their system by installing broken or incompatible
    versions.

  - It'd be much easier to provide a perl with a reduced core feature
    set, such as the unicode support mentioned above.

  - It'd be easier to check if a package actually worked with the
    minimal perl.

  - You could even drop everything necessary to bootstrap CPAN.


As far as I can tell, almost everything necessary to achieve the above
is already available in the form of Configure switches, so I guess the
effort required to implement it would be quite small.

The only thing worrying me slightly about this is the possibility that
it might lead to some sort of weird fork, which would lead to even more
pain.


Generally, I find the idea of a minimal perl that's neither called
`perl' nor installs /usr/bin/perl to be most appealing. Short of that,
requiring users to install the `perl' package to pull in all the
libraries included in the perl distribution on top of a minimal
core-perl doesn't sound too bad either. I would however be nice if that
minimal perl, without all the libraries installed, would identify itself
as such, for example in `perl -v' and `perl -V'.

But regardless of the approach Debian and Ubuntu are going to take, we'd
really love if as much of that as possible could happen upstream as the
perl 5 porters do after all have very similar goals.

Attachment: pgpBQWwCNqNNJ.pgp
Description: PGP signature


Reply to: