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
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
