develooper Front page | perl.perl5.porters | Postings from June 2009

bundling modules (was Re: Perl 5.10.1)

Thread Previous | Thread Next
Nicholas Clark
June 30, 2009 07:43
bundling modules (was Re: Perl 5.10.1)
Message ID:
On Wed, Jun 24, 2009 at 12:14:23PM +0200, Rafael Garcia-Suarez wrote:
> 2009/6/24 Ovid :
> > So Nick's suggestion of bundling everything is a compromise for those (like
> > myself) who would like to see the core language brought into the modern age
> > (it's soooooo close ... :) and those (like yourself) who have a more
> > conservative approach that's likely to be reassuring to existing code bases
> > (the darkpan is important).
> A bundle is good, but when producing a bundle, keep in mind a couple of
> points:
> * until 5.12 and its re-ordered @INC is out, modules distributed with
>   the core can't be superseded by newer versions without overwriting the
>   files, which is a big problem if you're installing the whole bundle as
>   a single rpm (for example)

I believe that this can be mitigated by configuring with a vendor prefix,
and installing the bundled modules to that, rather than either "perl",
or "siteperl"

Additionally, if OS vendors did this for <5.11, they'd avoid a lot of the
shadowing, aliasing and overwriting problems that currently happen.

I just built maint-5.10 with

./Configure -Dcc=ccache\ gcc -Dld=gcc -Dprefix=~/Sandpit/snap5.9.x-$patch  -Dvendorprefix=~/Sandpit/snap5.9.x-$patch -de && make -j3 perl

and I get this:


hence bundled modules installed to .../vendor_perl can be overridden by
the user installing to site_perl. As best I can see, there's no reason not
to do this if you're planning on bundling modules, *and* planning on letting
(or coping with) your end users upgrading them too.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About