Re: "Please drop perl dependency" bugs
On Thu, Nov 11, 2010 at 11:39:26AM +0100, Martin Pitt wrote:
> Niko Tyni [2010-11-09 22:40 +0200]:
> > Until now, the perl-base package has been provided mostly for the
> > benefit of the Debian Installer and for limiting the functionality in
> > the Essential:yes package set. I don't think it was ever the intention
> > that end user systems would be left with just the 'perl-base' package
> > by default.
> There are also perl library packages which don't import any particular
> Perl module, i. e. just use the core perl language. Also, libnss-mdns
> just uses "perl -i" in its postinst, but doesn't even ship perl
> modules. Do you think we can at least safely drop the perl dependency
> from those, since they don't make any assumptions about which modules
> perl-base ships? Since perl-base is essential, and there are
> maintainer and init scripts written in perl, it's guaranteed that
> /usr/bin/perl is available, after all.
I think the spirit of the current policy is that it's OK for the case
of maintainer scripts but not for the case of libraries. I'm pretty
sure it's _safe_ for both though, and it doesn't violate any 'must'
directive in the policy AFAICS.
> > I'd much rather see a solution where the Perl core (aside from perl-base)
> > is split into small binary packages so that package dependencies can be
> > declared with finer granularity and the installation footprint cost of
> > using standard library functions is lower.
>
> I agree, that'd be much cleaner. I just changed some 5 packages so far
> to get a feeling about how difficult this task would be.
>
> But I'm happy to split out proper libperl-* from perl-modules with the
> stuff that's generally needed in a normal install, if you prefer this.
The important thing to do is to discuss this upstream first. There are
also some implementation details relating to the dual lived modules that
are currently packaged separately in Debian. I think it comes down to
two questions:
- whether it's OK for a distro default installation to come with
/usr/bin/perl but not the full standard library, and require the
installation of a 'perl' package to pull in the rest
- whether it's OK for the 'perl' package to pull in newer
versions of dual lived modules than those shipped in the corresponding
upstream perl release
The reason why I think upstream may be more appreciative to the scheme
nowadays is that the Redhat/Fedora "perl-core" discussion referenced
earlier revolved mostly around the naming of the packages. I was left
with the impression that most people upstream thought it's OK to split
the core into smaller pieces as long as 'perl' pulls in it all.
I can bring this up on the perl5-porters list, but I'd like to get some
more input first, particularly from oldtimers like Brendan :) Assuming
upstream relations work out OK, are there other reasons why a more
fine grained split would be a bad idea?
--
Niko Tyni ntyni@debian.org
Reply to: