Re: "Please drop perl dependency" bugs
On Tue, Nov 16, 2010 at 1:46 PM, Niko Tyni <ntyni@debian.org> wrote:
> 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.
That makes a lot of sense. I'll keep my responses fairly brief as
well and let the discussion flow to perl5-porters.
>> 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.
I think you need to think about two audiences. One audience installs
things entirely with Debian packages. The other audience installs
things directly from CPAN, hopefully into a local library (not a
system library with sudo). For the former group, what you describe
works fine. For the latter group, it doesn't.
Assuming they realize/find-out that they have a crippled core perl,
they could (a) install missing packages or a "perl-full" package or
(b) build their own perl for personal use (in /usr/local/ or via
perlbrew). Either way, it creates a big stumbling block for anyone
expecting all of core perl available if the /usr/bin/perl exists.
My personal preference would be to optimize for the "average" user
rather than the "minimalist" user as the default, if at all possible.
>> 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.
I don't see that a crippled core perl package is very different in
principle. You still need to break everything to find the missing
dependencies. The difference is that the fix is just dependencies
instead of code.
If you have to stick with one /usr/bin/perl, then maybe an analogy to
something like how python is handled wouldn't be terrible (as I
understand it). I.e. A "perl-minimal" package and a "perl" package
(that also pulls in perl-doc). I guess that might be similar to
"perl-base" but more explicitly "minimal" and would allow for
installing "perl" to bring in "perl-doc" as well. Then it would seem
the question is whether a "perl-minimal" could be smaller than
perl-base and how many existing packages could be made to depend on
"perl-minimal" instead of "perl".
Or maybe you've been over that ground already and I missed it in the
older thread.
-- David
Reply to: