What's the push to require the latest Perl?

[Bill Cole]

On 5 Jan 2018, at 5:45 (-0500), Ryan Schmidt wrote:

> There's no problem here. Just because ports use perl5.24 or perl5.26 
> for their own purposes has no bearing on what you use for your own 
> personal projects.
[...]

Understood: Multiple Perl versions can co-exist and my fear of automated 
breakage was unfounded.

My only remaining concern is with the housekeeping aspects. It seems to 
me that ports should avoid over-specifying dependencies (e.g. 'perl5.26' 
instead of 'perl5' or 'p5.26-foo' instead of 'p5-foo') that cause the 
automatic installation of unnecessary duplicates of existing software. 
Maybe there's some overriding issue that I'm not seeing, but it seems to 
me a waste of time, disk space, and overall environment complexity to 
add all those redundant copies of perl modules and a technically 
unneeded perl core.

> If you have been using perl5.24 and p5.24 modules for your own 
> projects and now
> want to use perl5.26, simply install the p5.26 versions of the modules 
> you want.
>
> Ports that require a perl module must specify a dependency on a 
> specific perl version of that module (e.g. p5.24-... or p5.26-...). 
> Ports must not declare a dependency on the perl versionless "stub" 
> port (p5-...).

OK, so that specific rule seems wrong to me.

Most non-core Perl modules retain runtime backwards compatibility with a 
decade or more of 5.x core versions. I doubt that there's any software 
in existence outside of the Perl Core itself which requires 5.26 to 
build or run, or even which bakes in a specific Perl version at build 
time. Software that requires Perl only at build time never (in my 
experience) requires anything more specific than a minimum version of 
Perl (rarely 5.10 or later) and any required non-core modules (sometimes 
with a minimum module version, often not.) Making a MacPorts port 
pickier than its upstream software doesn't make much sense, especially 
in the case of modules that have been absorbed into the Perl Core but 
still exist as free-standing modules. Example: PathTools; if you install 
the port on a supported version of perl, you end up with an *OLDER* 
version than the one in Core.

I think a better approach would be to either require the p5-foo port OR 
(better) require path:${perl5.lib}/Foo.pm:p5.${perl5.major}-foo or 
(best) create a new syntax for dependencies that check for 
functionality, i.e. use the return value of 'perl -e "use Foo 6.66;"' to 
decide whether to install p5.${perl5.major}-foo @6.66 (or greater)

Of course, the last option is a substantial enhancement that needs 
careful thought and probably a significant amount of work. So, a bit of 
a fantasy...

> I have not used FreeBSD and am not familiar with the UPDATING file.

As Dave said, it's a central place for documenting pitfalls of port 
updates. It's human-readable but structured to be parseable to extract 
relevant stanzas programmatically. That enables the use of a command 
like "pkg updating -d 20170701" to see all of the warning notes for all 
of your installed ports that have updates since 2017-07-01. In theory, 
'port notes outdated' could do something similar in MacPorts but it 
would require maintainers to use the notes field consistently as a 
persistent record of changes that merit special attention beyond a 
simple 'port upgrade.' The advantage of an aggregated log of such 
changes like the UPDATING file is that it enables a project-wide policy 
on what should be noticed and how far back to retain old notices, and it 
would keep ever-growing records of change out of Portfiles.

-- 
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole