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

Re: deprecating

Thread Previous | Thread Next
Michael G Schwern
March 4, 2009 15:23
Re: deprecating
Message ID:
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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About