Front page | perl.perl5.porters |
Postings from April 2010
* Aaron Sherman <ajs@ajs.com> [2010-04-07 10:30]: > Platforms like modern Linux distributions get a Perl install > that's capable of doing what the OS needs it to do and then any > applications that rely on some other libraries can simply > depend on the platform-specific packages that they need and > they'll be pulled in. There's no real problem there... I agree to some extent. I suppose it would be a parallel to how most distros split libraries into a package containing the shared object and a -dev package containing the headers. We would just have to make sure that there’s a package that can be used to pull in everything that ships in batteries-included package, maybe using a virtual `perl` or `perl-dev` package that depends on `perl-core` and `perldocs` along with a few dozen other packages for modules. Something like that would be fine. > The problem arises when a platform doesn't provide advanced > dependency resolution of this sort. Worse, on some (dare I say, > legacy) platforms Perl is strictly after-market (e.g. Windows). > On these platforms, anything that the release du jour doesn't > install with is nearly unobtainable for someone packaging > software for use by others. Strawberry Perl seems to sufficiently disprove that worry. > Then the worst case gets even crazier if you assume that, for > example, Google App Engine might ever release their Perl > implementation (http://code.google.com/p/perl-appengine/). I don’t think that’s particularly crazy. GAE have their own Python version too. The platform is known to be somewhat kooky due to its peculiar needs. That’s fine if you ask me. > I think that Perl would be better off differentiating "core" > from "valuable domain-specific features," and then expanding > that latter category substantially, providing the same level of > support for a fully pre-compiled/ready-to-install support for > them as the nominal core. > > For example, what if we identified several key domains into > which modules fall, and for each domain, specify a unique (but > possibly inter-dependent) set of modules that might aid > a developer targeting those domains if and when a best practice > has taken shape. I think the best appeoach is to create the plumbing to allow anyone who feels up to this task to JFDI. No need to have long discussions about what kinds of committees are worth doing. Give people the tools, stay out of their way, and watch what happens. Maybe not much, maybe something great… we’ll see. The key is that the plumbing be such that it’s worth doing even small uses make it worth doing. > Right now, the antagonistic relationship between Perl's forever > increasing "core" and the platform maintainer's desire to keep > the default install in check is bad for everyone. There is no antagonism. The problem is simply that p5p has always consisted of very few people who actually *do* anything. Separating out the core from the batteries would allow using the resources of this group more wisely – with more focus. That is what was on my mind WRT this proposal. > By keeping an exact 1:1 mapping between old core and new > core+domains you let folks like Debian (just an example) ease > into the idea by continuing to distribute everything at no > added cost (it's all the same stuff). Yes, it was my idea that the batteries package would start out containing the non-pure-core modules that perl ships with today, for that reason. > Then, as packages ease into this, Perl can begin to expand each > domain as appropriate, letting platforms decide how to respond, > secure in the knowledge that their packagers have had time to > work out the new realities of dependency management for Perl. The maintenance of the batteries package will likely start out being in p5p’s hands simply for practical reasons. But I foresee that once the low-overhead opportunity exists, people like the project heads of the large CPAN frameworks, Adam Kennedy as the driver of many CPAN quality efforts, etc., will start pitching in – if only just by being involved in discussions more so than they have in the past. I expect a period of organic self-organisation; how the fruits of this may ultimately look like, I have no idea. But I know that whatever system turns out to work will be one where each step along its realisation is a small and obvious one to take from the previous step. Complex systems that work arise from simple systems that work. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next