What's the push to require the latest Perl?

[Bill Cole]

On 1 Jan 2018, at 14:55 (-0500), Craig Treleaven wrote:

>> On Dec 31, 2017, at 11:46 PM, Bill Cole 
>> <macportsusers-20171215 at billmail.scconsult.com> wrote:
>>
>> Ah, so apparently the reason this met total silence was that it got 
>> lost/dropped somewhere so only I thought it was posted. Odd...
>>
>> Reposted message:
>>
>> From: Bill Cole <macportsusers-20171215 at billmail.scconsult.com>
>> To: macports-users at lists.macports.org
>> Subject: What's the push to require the latest Perl?
>> Date: Fri, 15 Dec 2017 18:00:20 -0500
>>
>> In regards to https://trac.macports.org/ticket/55208 :
>>
>> In doing pre-upgrade due diligence I ran across this:
>>
>> # port rdeps p5.24-net-dns
>> The following ports are dependencies of p5.24-net-dns @1.140.0_0:
>>  perl5.24
>> [...]
>>  p5.24-net-libidn2
>>    libidn2
>>      pkgconfig
>>      autoconf
>>        xz
>>      automake
>>      libtool
>>        xattr
>>          unzip
>>      libunistring
>>        perl5
>>        texinfo
>>          help2man
>>            perl5.26
>>            p5.26-locale-gettext
>>
>>
>> That seems unhelpful... Why would help2man demand the absolute latest 
>> Perl? Well, because the Portfile says it does. However, in the real 
>> world, help2man is happy with any perl since 5.8.
>>
>> Doing a 'port -y upgrade outdated' reveals that multiple ports are 
>> threatening to demand perl5.26 if I try to upgrade them, like whois!? 
>> Because it needs perl to build???
>>
>> This is insanity. Can anyone convince me otherwise or even explain 
>> how this hasn't led to an angry mob with torches and pitchforks? 
>> Because I have one of each if anyone wants to join the revolt…
>
> I’m not the best to explain the situation, but the issue basically 
> comes down to manpower.  We have many thousands of ports and not all 
> that many active maintainers.

Understood. Always a problem in the FOSS world. I'd like to be able to 
offer help but cannot responsibly do so currently. I am grateful that 
there are people who can do so.

> It is felt that supporting multiple Perl versions drains resources 
> that would be better spent keeping up to date.  Especially since older 
> versions are no longer supported upstream or even receiving critical 
> security fixes.

Note that 5.24 still will be supported upstream for a few months. 
Hopefully all the issues with 5.26 in modules I rely on will be fixed 
before 5.28 comes out. Updating my whole Perl world is not an option 
quite yet.

> Since most users receive and install pre-compiled binaries, it 
> doesn’t present a big burden when they upgrade.

Not everyone can do that. It would help if I could, since eliminating 
build dependencies greatly reduces the places in the dependency forest 
where the Perl core will get upgraded as a dependency.

> Should a user be concerned about old versions wasting disk space, the 
> port reclaim command is available to pare things down.

Disk space is not the problem. Here's the problem:

***There is no canonical documented process for cleanly updating the 
MacPorts Perl universe and specifying only the latest Perl version in 
dependencies appears at first encounter to make that universe 
fragile.***

After some experimentation on a non-critical system, it seems now that 
my alarm over seeing 5.26 dragged in was not so justified, because it 
doesn't grab the /opt/local/bin/perl{,5} symlinks. So the existing 
working 5.24 world is apparently safe from damage until I switch the 
perl5 port to the 5.26 variant. It seems. I still haven't worked out an 
upgrade process any better than I've used in the past: feeding the list 
of p5.x-* ports into a script that installs the new version of each one 
then switching the symlinks by switching the perl5 variant and finally 
removing all the old versions.

Has the MacPorts core team considered the implementation of an analog to 
the FreeBSD 'UPDATING' file? Having a reference for updates that require 
special procedures would make it less likely that users are startled by 
updates they aren't really prepared for.

> As the home page says: "We provide a single software tree that 
> attempts to track the latest release of every software title (port) we 
> distribute”.  Note the _latest release_ part.

Yeah, but it isn't really feasible to always use the latest Perl or any 
other language whose ecosystem is the product of many independent module 
authors.

-- 
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