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.

[dluke@…]

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?

[dluke@…]

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?

[dluke@…]

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.

[dluke@…]

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.