perl5 portgroup should be able to write in privlib dir for the bundled modules

[nox@…]

Some perl modules are bundled in the perl5.8 port. Those who are also available through MacPorts (e.g. p5-getopt-long, p5-pathtools and p5-digest) should be installed directly into perl's privlib dir.

[nox@…]

Here are the ports which modules are bundled in perl5.8 :

• p5-cgi.pm (which should be names p5-cgi (see #12711), by the way)
• p5-data-dumper
• p5-digest-md5
• p5-file-temp (a port has been specially created to take care of its issue: p5-file-temp-svkonly (#12050))
• p5-getopt-long
• p5-math-bigint
• p5-math-bigrat
• p5-mime-base64
• p5-net
• p5-text-balanced
• p5-time-hires
• p5-time-modules
• p5-unicode-collate
• p5-pathtools

Maybe there are others, though.

[nox@…]

One more:

• p5-test-harness

[markd@…]

FYI, when this is fixed, #10978 can be closed.

[narf_tm@…]

I have always hated that these ports require you to use force. Now we are trying to make that the practice to follow!? Why aren't we fixing the Perl @INC order like other distros? This allows Perl modules that are installed to take priority over the Perl base modules. I have listed the paths for MacPorts and Debian below. You can see that Debian has many locations Perl modules can be installed and used before the base Perl modules are used. I think all the vendor paths should be moved to the top of the @INC list (this needs to be fixed in the perl5.8 Portfile). Then all these ports can stop requiring force to be useful.

macports @INC: /opt/local/lib/perl5/5.8.8/darwin-2level /opt/local/lib/perl5/5.8.8 /opt/local/lib/perl5/site_perl/5.8.8/darwin-2level /opt/local/lib/perl5/site_perl/5.8.8 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level /opt/local/lib/perl5/vendor_perl/5.8.8 /opt/local/lib/perl5/vendor_perl

debian @INC: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl

[vinc17@…]

Some questions remain unresolved: what about the man pages and the binaries? Also, if some module has been updated, then it should be installed whenever perl5.8 has been installed (as if it were updated in the perl5.8 port itself).

This bug blocks the upgrade of other software and is really annoying. Could it be eventually fixed?

[vinc17@…]

Another solution would be to remove files provided by individual ports from the perl5.8 port.

[narf_tm@…]

I still do not think we should be forcing Perl modules to replace Perl core modules. I also do not think that removing files from Perl is a decent option. This mean every time a core module gets updated, the Perl port is going to have to be modified to accommodate the newer module port.

Why don't we do what the Perl INSTALL file suggests?

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

BSDPAN_DEST=	${PREFIX}/lib/perl5/${PERL_VER}/BSDPAN
-Dccflags=-DAPPLLIB_EXP=\"${BSDPAN_DEST}\"

Call it what ever you want and use that path for the Perl ports instead of vendor. This seems like the most logical and sane solution to me. It is also the solution most other *nix distros seem to have used.

Can we open this option up for discussion?

[nox@…]

Replying to vinc17@macports.org:

Another solution would be to remove files provided by individual ports from the perl5.8 port.

That's not possible, as perl5.8 would depend on p5-getopt-long (for example) which would depend on perl5.8...

The idea of using APPLLIB_EXP seems like a very good one! We should either do that or reverse the @INC path. Either way we can't let this problem lives any longer, it has became quite a bother.

[vinc17@…]

Replying to narf_tm@macports.org:

I also do not think that removing files from Perl is a decent option. This mean every time a core module gets updated, the Perl port is going to have to be modified to accommodate the newer module port.

Only the first time each module gets updated (i.e. whenever a module gets removed from the Perl port, but only in such cases). I don't think that would be too often in practice.

Why don't we do what the Perl INSTALL file suggests?

Does that also solve the problem for binaries and man pages? IMHO, it is possible to install them in another place too. The user would have to add the corresponding path to his .profile (or similar rc file). However, he has already needed to do that for ${prefix}/bin.

Can we open this option up for discussion?

If you're OK with the above, yes.

Replying to nox@macports.org:

That's not possible, as perl5.8 would depend on p5-getopt-long (for example) which would depend on perl5.8...

It would be possible with a meta-port that would depend on both the Perl core port and the module port, and p5-getopt-long would depend on the Perl core port. BTW, I don't know if a depends_run p5-getopt-long could be added for the Perl core port (I'd say that there should be no problems with cycles in run dependencies), though this shouldn't be completely necessary.

[nox@…]

Nope. Perl core needs the getopt-long module. So we can't remove it from perl5.8 files. Except if we do that in a post-destroot stage, but that would be more of a workaround than a real bugfix. As narf_tm said, that would be too difficult to maintain, even though updates are not released that often.

Playing around with either @INC or APPLLIB_EXP still seems like the best bugfix for perl script files.

But as you said, we still need to find a solution for manpages and binaries.

[vinc17@…]

Replying to nox@macports.org:

Nope. Perl core needs the getopt-long module. So we can't remove it from perl5.8 files. Except if we do that in a post-destroot stage, but that would be more of a workaround than a real bugfix.

Yes, I meant at this stage. And I don't see this as a workaround.

As narf_tm said, that would be too difficult to maintain, even though updates are not released that often.

Actually, I find it easier to maintain. Otherwise one has the following problem: Assume that some module M provided by the Perl core gets updated separately by upstream and a new port is added for this module to use this new version (as what happened for the getopt-long module). Then all the ports that use this module should be updated to depend on this new port (providing the new version of M). With the meta-port solution, ports using Perl could depend only on the meta-port and would not need to be updated whenever a new port providing a core module is added.

[nox@…]

Destrooting a file and then delete it before the install stage is a workaround.

Everyport that uses a core module should depend on its specific port only if it needs a greater version than the one provided by perl5.8. We can check if it built without the need of this specific port with trace mode.

[vinc17@…]

Replying to nox@macports.org:

Everyport that uses a core module should depend on its specific port only if it needs a greater version than the one provided by perl5.8.

Unfortunately, not all port maintainers agree with you, and add a useless dependency. If you want an example, please see bug #13745 (I don't have any problem with my local port where the dependency has been removed).

[nox@…]

The installation of a custom p5-test-harness in #13745 is unneeded, you're right. But it doesn't break anything. If a core module file is omitted in your solution, we will need to force installation again, whereas a reversed @INC path avoids this shortcoming. So if we create a new port for an updated core module, we'll have to increase the revision of perl base port and to remove the files of the core module from it. That's not elegant.

[vinc17@…]

Replying to nox@macports.org:

The installation of a custom p5-test-harness in #13745 is unneeded, you're right. But it doesn't break anything.

It currently breaks upgrades if the -f option isn't used.

If a core module file is omitted in your solution, we will need to force installation again,

I suppose you mean an upgrade of the Perl core port.

whereas a reversed @INC path avoids this shortcoming.

Yes, but there's a still problem for the binaries and man pages with this solution. The only workaround I can see is that the user would need to modify his $PATH environment variable in his shell rc file(s). But note that if you regard this modification as acceptable, then the user could also modify his $PERL5LIB environment variable at the same time, meaning that the reversed @INC path is completely unnecessary.

So if we create a new port for an updated core module, we'll have to increase the revision of perl base port and to remove the files of the core module from it. That's not elegant.

I don't think there's any elegant solution.

[nox@…]

APPLLIB_EXP is in fact a bad idea. The Perl modules makefiles handle site, vendor and priv installations, they don't do appl ones. You can't play around with INSTALLDIRS and APPLLIB_EXP.

[macports@…]

I also think we should do what the Perl INSTALL file (and the FreeBSD port) suggests. At least this issue should be solved with a workaround until a "real" solution emerges, since breakage like this makes users shun away from using MacPorts. (My debian-using colleagues weren't very impressed by issues like #15609).

[macports@…]

Cc Me!

[bruce@…]

Is there a solution (or a workaround) that a regular user can apply? I get this error maybe 100 times when I try to run "upgrade installed". Between this and some ports requiring teTeX and others requiring texlive, it seems (to someone who is just trying to make use of the software) that my macports tree is currently pretty much unmaintainable.

[macsforever2000@…]

Cc Me!

[macsforever2000@…]

I don't completely understand everything involved in fixing this issue, but I do want this issue fixed. So sorry if this is naive.

Given that:

1. All of the aforementioned sub-ports (e.g. p5-getopt-long, etc.) are already in perl and that they are important.
2. People using Perl on MacPorts want the latest cutting edge but stable version of Perl.
3. We all want Perl in MacPorts to "just work" without conflicts.

I propose that all of the sub-ports should be incorporated directly into the perl5.8 port. The sub-ports will be removed as separate ports. When one of the sub-ports like p5-getopt-long is updated, then the perl5.8 port is updated and the revision incremented.

[febeling@…]

Cc Me!