NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

SDKs (Score:2)

by barbie (2653)

This is similar to the SDK idea I posted [perl.org] some time ago. I still haven't had time to take that particular idea further, but creating an SDK to handle a known Database install, or Templating install or whatever, would seem a better idea than bundling them into a single core distribution.
- Re: (Score:2)
  
  by davorg (18)
  
  This is the same SDK idea that has been knocking around since... well, certainly since I first went to a Perl conference in (I think) 2000 :-)
So what would be the point? (Score:1)

by sigzero (5768)

I don't like the idea either. Maybe a re-think of "core" should happen. I typically install Perl and then I have a list of standard modules that I use and they get installed via CPAN. Everyone and their mother is going to have a different list of what they consider useful. Keep the install as lean as possible. If I want something, I will get it.
Add-on packages (Score:2)

by bart (450)

I don't like the idea of alternative Perl cores. I'd prefer add-on packages, which would be like bundles, except they'd include everything and the kitchen sink, for specific distros. They'd include everything but the core perl distro.

It would be a bit like PPM distributions for ActivePerl, or APTGET packages for some distros of Linux.

The good thing is that there is no clash if you want the module bundles of two different "cores". You ought to be able to just install both, without installing Perl twice.

There