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
+========================================================+
| *---------------- [EMAIL PROTECTED] ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
