p5-getopt-long and perl5.8 - activation error

[Matthew Ross]

Why don't we leave the @INC in the order it is now so we don't break  
current perl ports and use the APPLLIB_EXP option like FreeBSD does?

The Perl INSTALL file explains it's use:

"There is one other way of adding paths to @INC at perl build time, and
that is by setting the APPLLIB_EXP C pre-processor token to a colon-  
separated list of directories, like this sh Configure -Accflags='- 
DAPPLLIB_EXP=\"/usr/libperl\"' The directories defined by APPLLIB_EXP  
get added to @INC I<first>, ahead of any others, and so provide a way  
to override the standard perl modules should you, for example, want to  
distribute fixes without touching the perl distribution proper. And,  
like otherlib dirs, version and architecture specific subdirectories  
are also searched, if present, at run time."

We can use FreeBSD's Perl port as a good example of this.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/Makefile?rev=1.94
Instead of using vendor they have a directory called BSDPAN.

Call it whatever you like...

If we make this new directory the new default over vendor, as things  
are upgraded they will be moved into this directory.
Theoretically everything should work as things are transitioned.



On Feb 6, 2008, at 8:54 AM, Daniel J. Luke wrote:

> On Feb 6, 2008, at 4:49 AM, N_Ox wrote:
>> Le 5 févr. 08 à 16:13, Daniel J. Luke a écrit :
>>> We really need to do one of a couple of things:
>>>
>>> - Change the perl port to install a minimum perl along with  
>>> individual ports for each of the CORE modules
>>> - Change the @INC ordering (thus making our perl act differently  
>>> from the upstream perl and potentially break any ports that rely  
>>> on the current behavior of @INC ordering)
>>> - Force users to set $PERL5LIB and/or patch everything to use a  
>>> custom $PERL5LIB
>>>
>>> Since there are serious drawbacks to each approach, and no one  
>>> seems to have had time to work out a complete solution, we're  
>>> stuck with the status-quo
>>>
>>> I'm sure everyone would be happy if you have an implementation of  
>>> one of those solutions (or something else that's better) available  
>>> for all of us to use.
>>
>> I disagree, the @INC modification doesn't have serious drawbacks,  
>> other software-management systems like Gentoo Portage works great  
>> with this method.
>
>
> It's the transition that's a problem (since we don't actually test  
> our ports we can't verify that we won't break lots of things).
>
> Changing the @INC order will change which modules get loaded for  
> things already installed and working,
>
> --
> Daniel J. Luke
> +========================================================+
> | *---------------- dluke at geeklair.net ----------------* |
> | *-------------- http://www.geeklair.net -------------* |
> +========================================================+
> |   Opinions expressed are mine and do not necessarily   |
> |          reflect the opinions of my employer.          |
> +========================================================+
>
>
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-users