p5* ports - what a mess!

[RJVB (René Bertin)]

Sorry for the title, but someone has to say it. I've hesitated between "defect", "enhancement" and "request" for the ticket type but went with "defect" in the end. Feel free to change that.

Regularly I find that perl5 ports I have installed and depended on on 1 system have disappeared when I try to install them on another system. There used to be a time (IIRC) where one could just depend on port:perl5 and whatever port:p5-foo were required. That's probably still the case for the main port but it just doesn't work anymore for the others. What's the rationale for not including all versions from the main port in the p5-foo ports? For instance, in the snapshot of the main repo I have I see that port:perl5 has Sub-ports: perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, perl5.26, perl5.28, perl5.30, perl5.32, perl5.34, perl5.36 but the p5-foo ports have perl5.branches 5.28 5.30 5.32 5.34 . That can't be right (and frankly, that variable should be set in a PG and only overridden in individual Portfiles when unavoidable).

Also, I see the perl5 PG now misdefines perl5.major as major.minor, which is probably part of the reason of the mess.

I am aware that some of the p5.xy-foo ports install binary shared libraries, but as far as I can tell the ones I have installed on this machine do not link to libraries provided by the corresponding port:perl5.xy.

I do not see any evidence that perl is included in the port select mechanism.

In other words, wouldn't it be much cleaner to provide a port:perl5 that is not just a dependent but installs an actual default version of perl5, which gets updated regularly but not more often than strictly necessary, and which can be used preferentially for things like build dependencies? Updating that main-default port would only have to trigger a rebuild of the corresponding p5-foo ports when there's been a ABI break (very rare, I assume since Linux distros do not seem to maintain separate lineages of perl packages).

This would address the issues I'm referring to above, and also put an end to (a priori) the ever-increasing amount of obsolete p5-foo ports that never get cleaned up if the user doesn't do it because "who knows what they're needed for".

Having such a main/default perl5 version is not incompatible with having a number of specific versions with their corresponding p5-foo ports, for users who have specific needs.

---

Of course it could also be an idea to allow advanced users to set a preferred perl5 version in macports.conf (which would get included in perl5.branches) - and let the perl5 PG print out a warning when it's really time to bump that version.