Front page | perl.perl5.porters |
Postings from March 2009
Nicholas Clark wrote:
> 5.11's @INC order now has siteperl ahead of the core library:
>
> Compiled at Mar 4 2009 20:54:46
> @INC:
> /home/nick/Sandpit/snap5.9.x-GitLive-blead-731-ge74f3fd/lib/perl5/site_perl/5.11.0/x86_64-linux-thread-multi
> /home/nick/Sandpit/snap5.9.x-GitLive-blead-731-ge74f3fd/lib/perl5/site_perl/5.11.0
> /home/nick/Sandpit/snap5.9.x-GitLive-blead-731-ge74f3fd/lib/perl5/5.11.0/x86_64-linux-thread-multi
> /home/nick/Sandpit/snap5.9.x-GitLive-blead-731-ge74f3fd/lib/perl5/5.11.0
> .
Huzzah! Is the order site, vendor, core now?
> This means that updates of dual life modules from CPAN need not go in "perl" -
> if they install to "site" (like any other module) they'll be picked up first.
>
> In fact, "need" is a bit weak - we don't really *want* them to go to "perl"
> any more, because it violates the nice segregation the better @INC order gives
> - nothing need touch the core's installed tree once it's been installed.
Exactly. Everything from 5.11 on should default to site now.
> Hence why the question as to whether we should
>
> a: patch the Makefile.PL of all dual life modules to have INSTALLDIRS be
> "site" for 5.11 onwards (and still "perl" for pre-5.11)
>
> b: patch MakeMaker to politely ignore "perl" on 5.11 and later, and substitute
> "site"
"A" leads to fun code like:
INSTALLDIRS => (5.006002 <= $] and $] < 5.011) ? 'perl' : 'site';
"B" leads to fun head scratching when someone really wants to install into
"perl" for whatever reason. A vendor building an updated perl source tree maybe.
And then there's the issue where certain distributions have been doing site,
vendor, core for a while now (Debian and friends).
There's option "C" to add a new option to MakeMaker to make the logic easier.
Like: added_to_core("5.6.2") that does the right thing but then you run afoul
of backwards compatibility.
I'm inclined towards A. It only has to be done once, in one place and by a
small set of modules. The set will not grow since any new dual-life modules
will not need the INSTALLDIRS hack in the first place.
Oooh, how about this? Store the order in %Config!
($Config{inc_order}[0] ne 'site' and $] >= 5.006002)
? (INSTALLDIRS => "perl")
: ()
This is a bit more involved, but it allows folks like Debian to patch
$Config{inc_order} into their existing Perls solving the Debian installation
problem and the 5.11 problem.
--
Stabbing you in the face so you don't have to.
Thread Previous
|
Thread Next