Re: "Please drop perl dependency" bugs
On Tue, Nov 16, 2010 at 05:31:49PM -0500, David Golden wrote:
> On Tue, Nov 16, 2010 at 1:46 PM, Niko Tyni <email@example.com> wrote:
> >> 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.
Oh, I think CPAN.pm and CPANPLUS.pm should definitely be in the full
'perl' package or something that pulls it in. Ideally, they would get
automatically accompanied by things like gcc and make.
I think this is a separate issue from your earlier point, which I read
as handling Debian packaging (official or otherwise) of CPAN modules.
Sorry if I misunderstood you.
> >> 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.
> > 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.
I don't intend to break anything. All the packages in Debian needing Perl
currently either depend on 'perl' [which would continue to exist and
offer all the current functionality], or only use functionality from
'perl-base', which does not need to be touched at all.
The packages depending on 'perl' could then be modified to more fine
grained ones gradually over time, giving a smooth transition.
> 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".
I wasn't going for anything smaller than perl-base.
I'm thinking of something like
(no change from now)
Package: perl-libs (or whatever)
contains all the standard libraries that aren't in the separate packages
an example of a separate binary package, built from the perl tarball, not
needing anything outside perl-base
Depends: perl-base (or perl-libs if necessary)
an example of a separate package, possibly coming from its own source
package from CPAN and not the perl tarball
Depends: perl-libs, libfile-basename-perl, libcgi-pm-perl, ...
- might contain CPAN.pm and CPANPLUS.pm for reasons described above
- eventually when enough packages have been converted to use perl-libs,
this could depend on perl-doc as well
This way Ubuntu could possibly manage with just perl-base and
libfile-basename-perl and a few other separate modules on their CDs without
patching the packages to reimplement standard library functions.
Eventually, Debian users installing just packaged Perl applications would
normally get perl-libs and maybe a few other separate module packages.
And I could hopefully dump the maintenance of the separately packaged
dual life modules to the Debian Perl Group :)
Niko Tyni firstname.lastname@example.org