Front page | perl.perl5.porters |
Postings from April 2010
On Mon, Apr 5, 2010 at 19:54, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: > * Ævar Arnfjörð Bjarmason <avarab@gmail.com> [2010-04-05 21:35]: >> But of course having all that stuff in core means maintaining >> it indefinitely, which means more strain on the porters. >> I wouldn't suggest something like "let's drop the top 100 CPAN >> module into core" without *very* widespread consensus on that >> point. > > A while ago I suggested on #p5p that it would be cool if the > whole dual-life tree in the core was reduced down to dropping > actual tarballs from CPAN – not even unpacked. That would not > only make it trivial to keep the dual-life stuff in core up to > date with their CPAN upstreams, it would also make it very easy > for anyone to build a batteries-included version of the core. > Ideally p5p would endorse one particular such effort (maybe the > Kensho people would build that, f.ex.), in that OS vendors would > be told to use that package as the basis for theirs. Then p5p > could concentrate on maintaining a slim core and downstream would > still get all the batteries they need in one neat package. For > the vendors who want to go that route it would also become easier > to split out the perl core package into several distro packages. > > The suggestion was well received on #p5p, at least. It's a great idea and I (and it seems like others too) would be willing to help make that happen. There's no reason that the state of core (as in what's normally in Git) has to reflect what eventually gets shipped to end users via OS distributors. The only potential problem with doing it like this is that it might be harder to convince vendors to participate. There are a lot of vendors who aren't too fond of Perl and only keep it around for backwards comparability, maybe they only keep upgrading it because "it's in the 8000 item release checklist along with upgrading everything else". If we put out 5.* saying "We're slim now. You can install this slim core + old libraries from classic.tar.gz or (and we really recommend this!) lots of Moose/POE/DBI/etc. sugar from chocolate.tar.gz" someone at say Apple might react to that as "Thanks but no thanks, we'll just take classic.tar.gz, we have no interest in providing anything but bare-minimal Perl support anyway". Even worse, they might decide that they don't really need any libraries, all they use Perl for anyway are these 500 perl4-era scripts that are part of the core OS. Dropping classic.tar.gz just saved us 5MB on the install CD! I could see Debian (and by proxy, Ubuntu) going the latter route. They already prune perldoc from their Perl release because they're just including it in the base system to bootstrap debconf.Thread Previous | Thread Next