perl5.8 @INC path should be reversed to be able to include vendorlib first.

[nox@…]

There's currently some ports which need to overwrite perl5.8 core modules (see #12710 for a short list of them). I think this is a bad practice and that we should instead patch perl5.8 to set @INC in a different order.

Here is a patch which do this and that update the other ports to correctly install in vendorlib.

I'm adding those ports maintainers to the Cc field.

[nox@…]

I see I've forgot a lot of those ports in my patch. I'll add a new one in short time.

[nox@…]

In fact, I've not forgotten any port. Those ports already install in vendorlib, which renders them useless for the time being.

[danielluke (Daniel J. Luke)]

Note that this has been discussed before and it was eventually decided that the current method (requiring install with -f) is the lesser of many potentially evil options.

See discussion in #11043 and #11175

[nox@…]

I don't know about other ports management, but I know this is the solution chosen by Portage and I've not experienced any problem using Gentoo. As I have written in #12710, there's a lot of ports which are rendered useless by the current @INC order.

Maybe we should reconsider this policy?

[danielluke (Daniel J. Luke)]

The ports aren't rendered useless as "use MODULE version;" will still load the newer one. It's just that scripts that had "use MODULE;" will get the perl-dist one (unless the port overwrites it and is installed with -f) and not the newer one (which may or may not be what the end-user expects to have happen).

I personally would rather have perl search site, vendor, and then private (in that order) everywhere, but I think it does make sense to have macports-provided perl match a normal perl install as much as possible.

[nox@…]

Then why don't we patch other ports to explicitely request a specific version?

[danielluke (Daniel J. Luke)]

The perl community generally updates modules that are distributed with perl by overwriting those modules, we're simply replicating this "standard" behavior within macports.

[nox@…]

This "standard" behavior is often called a "bug" on -users@, the whole '-f' thing scare them.

[danielluke (Daniel J. Luke)]

That's because base/ doesn't allow a portfile to say that it's going to overwrite files that belong to the perl5.8 port, and that it's OK (and to not require -f from the user, and not enable all of the other stuff that -f enables).

[nox@…]

There's another shortcoming with the force policy: Every port which depends on a perl core module (e.g. Getopt::Long) will failed to build with trace mode enabled if it does not explicitely depends on the port which overwrites this core module.

As Getopt::Long is used by perl5.8 own's core module, every p5-* port will fail in trace mode.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

​path-Portfile.diff ​patch-perl.c.diff change the order of @INC.

​patch-p5-test-simple.diff patches p5-test-simple to install into the site_perl directory.
The manpages are renamed to avoid conflict.

p5-test-simple is newer than the one provided by perl5.8, so

${prefix}/bin/perl -e 'use Test::Builder 0.86'

should test if the reordering is working.

[ghosthound]

perl5.8 Portfile patch to alter @INC

[ghosthound]

patch for perl5.8 perl.c to alter @INC

[ghosthound]

patch for p5-test-simple to go with perl5.8 @INC inversion

[ghosthound]

patch for p5-scalar-list-utils to go with perl5.8 @INC change

[ghosthound]

I've added several patch files to this ticket to do what I've tested for altering the perl5.8 @INC array - making perl search for modules in site_perl, vendor_perl, and then the base perl5.8, as well as changes to the Portfile to avoid man page collisions when p5-* modules are installed. There are also patches for two perl modules that required -f before this change, p5-test-simple and p5-scalar-list-utils - they now do not require -f to install and their modules are picked up by perl5.8 if installed. So far I've tested for man page collision with the above and known items like p5-cgi, no problems with collisions. p5-* man pages are detected before the mac-ports installed ones and before the system installed p5-* man pages. The only problem is that the system installed p5-* man pages are found before the perl5.8 man pages, I'm not seeing a clean solution for that without requiring alteration of /etc/man.conf or the like. I've also tested installing ~75 modules and using them, no (detected) problems there either.

The patches to test are:

Portfile.20090310.1655.patch

patch-perl.c.2.diff

p5-test-simple.Portfile.patch

p5-scalar-list-utils.Portfile.patch

Please report any success/failure shortly, I'd like to commit this by the end of the week.

As well, I figure on making the same @INC and man page changes for perl5.10 so there are no issues with some p5-* ports working with perl5.8 and not with perl5.10.

[ghosthound]

perl5.8 @INC change committed in r48955, please test

[ghosthound]

closing due to test timeout, please re-open if you find problems.

[(none)]

Milestone Port Bugs deleted