"Please drop perl dependency" bugs
(background: at least #602919, #602920, #602928, #602931)
On Tue, Nov 09, 2010 at 01:56:34PM +0100, Martin Pitt wrote:
> in Ubuntu we are trying to get rid of Perl in the default installation
> (that is, the full Perl, not perl-base of course); for this I'm
> currently removing the remaining reverse dependencies.
While I'm sympathetic to the goal of reducing the default Perl
installation footprint, I think this merits a discussion.
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.
The Debian Perl Policy currently states:
Note that the perl-base package is intended only to provide for
exceptional circumstances and the contents may change. In general,
only packages which form part of the base system should use only the
facilities of perl-base rather than declaring a dependency on perl.
At the very least, if we take the path Ubuntu has chosen, we should
update this part of the policy.
IMO the 'contents may change' part above is rather optimistic and removing
functionality from perl-base is already practically impossible. I don't
think this alone is a sufficient justification for prohibiting the use
of perl-base outside the base system.
Another point we need to consider is upstream relations. The
result of this strategy is that the vast majority of users get a
default installation with /usr/bin/perl but not the full standard
library. Upstream has been somewhat sensitive in this area [1], and the
plan should definitely be brought up on the perl5-porters list too.
I don't expect too much protest about this as long as installing the
'perl' package still gives the "Full Perl experience" (except the docs,
but we've already crossed that bridge.)
I understand Fedora is doing something similar with 'perl' for the full
installation and 'perl-minimal' corresponding to our 'perl-base'.
> With this patch, this package will work with just perl-base.
I generally dislike the idea of packages reimplementing standard library
functions like dirname() in order to reduce the dependencies. This creates
patches that are not useful upstream, adding to the maintenance burden
in the long run.
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'm not sure how far this should be taken, but at least all the dual
lived modules could be split out easily. The rest should probably be
considered on a case-by-case basis; circular dependencies between
modules may cause issues here.
[1] A relatively recent related discussion can be found through
http://lwn.net/Articles/348084/
Feedback would be welcome.
--
Niko Tyni ntyni@debian.org
Reply to: