perl5: obsolete subports perl5.16 perl5.18 perl5.20

[dbevans (David B. Evans)]

As far as I can see, all ports with perl dependencies and/or perl variants now only refer to perl5.22. Subports perl5.16 perl5.18 perl5.20 have no dependents nor variants referring to them and may now be obsoleted.

[mojca (Mojca Miklavec)]

It's true that they are no longer needed, but we might get similar requests like a while ago when users were asking for the old perl ports (like perl5.14) to stay.

Honestly I don't know what to do. The old ports themselves don't really do any harm nor do they add any significant overhead (like the modules do).

[dbevans (David B. Evans)]

As I understand it, we decided to support only the current stable version of perl -- currently 5.22. So under that criterion any older versions should be obsoleted. I expect that perl5.22 will be obsoleted when perl5.24 is published and we convert to that stable version.

[dbevans (David B. Evans)]

A slightly more permissive approach would be to follow ​the perl developers policy and obsolete all perl versions that are not supported upstream. As of the release of perl 5.22, perl5.18 and earlier became unsupported. Upon the release of perl5.24 support for perl5.20 will cease and so on.

[gnw3]

Some ports, e.g., logwatch (​https://trac.macports.org/ticket/50323), can run with perl 5.22 but give deprecation warnings. These warnings may come from rarely used sections of legacy perl code, so it seems reasonable to follow the perl developers policy to give people time to discover and fix deprecated usages.

[danielluke (Daniel J. Luke)]

We should obsolete all of them (or at least all of them that aren't supported upstream). End users who really want old perl can pull the old pre-obsolete portfile into a local repo (or could have stepped up to maintain the old port).

[dbevans (David B. Evans)]

Replying to gnwiii@…:

Some ports, e.g., logwatch (​https://trac.macports.org/ticket/50323), can run with perl 5.22 but give deprecation warnings. These warnings may come from rarely used sections of legacy perl code, so it seems reasonable to follow the perl developers policy to give people time to discover and fix deprecated usages.

Fixed in r145378. In this case, the upstream developers never noticed the problem even though these deprecations have been in place since perl 5.21 (more than a year). Moving to perl 5.22 as the default revealed the problem resulting in your ticket and an upstream fix. One more reason why we shouldn't promote the use of obsolete perl versions,

[dbevans (David B. Evans)]

Replying to dluke@…:

We should obsolete all of them (or at least all of them that aren't supported upstream). End users who really want old perl can pull the old pre-obsolete portfile into a local repo (or could have stepped up to maintain the old port).

Agreed. We've gone to a lot of work to only support one version of perl. At this point, it makes no sense to me to keep perl versions that we, ourselves, don't support in applications or with modules.

[mojca (Mojca Miklavec)]

There were only three answers on the ​mailing list. I gladly do whatever consensus we happen to reach, but it would be nice to have somewhat consistent rules also for other ports. The number of answers was way smaller than expected though.

(I just installed the long forgotten python33 and then even python32 for the sake of debugging why one of my ports didn't run properly with python34 after I added a huge patch to introduce compatibility with Python 3. And then uninstalled them again.)

And no, I don't need Perl 5.16 at all, I'm just not sure if we want to prevent all users from using it. Or would at least like to see some more feedback and more consensum from the community.

[danielluke (Daniel J. Luke)]

Not many comments because no one cares about the old perls (for some sets of 'no one').

The reality is that it's really easy to keep cruft like that around because it keeps working and no one complains. However, we do our users a dis-service distributing software that's not maintained upstream.

For the very few use-cases where people actually need the old version, they can resurrect the port (and/or someone could run an alternate ports tree with just "old unmaintained crap" for those who really want to have it).

[dbevans (David B. Evans)]

Replying to mojca@…:

There were only three answers on the ​mailing list. I gladly do whatever consensus we happen to reach, but it would be nice to have somewhat consistent rules also for other ports. The number of answers was way smaller than expected though.

(I just installed the long forgotten python33 and then even python32 for the sake of debugging why one of my ports didn't run properly with python34 after I added a huge patch to introduce compatibility with Python 3. And then uninstalled them again.)

And no, I don't need Perl 5.16 at all, I'm just not sure if we want to prevent all users from using it. Or would at least like to see some more feedback and more consensum from the community.

I don't think there's much more to say about this other than to make a decision one way or the other and close the ticket. Since these are all now contained as subports in perl5 and you're the maintainer, I'm happy to go with whatever decision you think is right.

[pixilla (Bradley Giesbrecht)]

Replying to dluke@…:

Not many comments because no one cares about the old perls (for some sets of 'no one').

The reality is that it's really easy to keep cruft like that around because it keeps working and no one complains. However, we do our users a dis-service distributing software that's not maintained upstream.

For the very few use-cases where people actually need the old version, they can resurrect the port (and/or someone could run an alternate ports tree with just "old unmaintained crap" for those who really want to have it).

+1

[mojca (Mojca Miklavec)]

I would like to wait for the discussion during the MacPorts meeting. If nothing else, I would at least like to see similar guidelines about port removal (or non-removal) across a wider spectrum of ports rather than just decide about Perl alone.

[dbevans (David B. Evans)]

Sounds reasonable. However, it may be simplistic to think that one blanket policy would fit all ports.

In the perl case, I think these are the issues that might be considered:

• is it useful to support outdated versions of perl that are no longer supported upstream by updates or security fixes?
• does it make sense to commit scarce maintainer resources to maintaining such outdated software?
• does anyone really care? (see comments from lduke, pixilla above)
• are these outdated versions useful when we don't support up-to-date modules for them (their functionality is currently limited to those modules that were shipped as core modules without further update)?
• if there is a point in time where these ports should be removed, when is that? What's the criteria?
• have any of the current perl ports met this criteria (and should be immediately removed)?
• at what point in the future might additional ports meet this criteria? (e.g. when new versions are released upstream, etc)
• once a policy is established, how can we document this policy and make that documentation readily available to the maintainer community?

<soapbox>
This last question is one that I consider to an important issue with respect to any MacPorts policy. IMO, there would be much less indecision about what to do in any given case if there was a well documented set of written policies to which a maintainer could refer. Currently, any such policy is more of an oral tradition and varies according to who is telling the story. Many organizations maintain something like a "policy & procedures" manual. Why not MacPorts?
<\soapbox>

I'll be interested to hear what the meeting attendees thing about these topics. Thanks for organizing the meeting.

[dbevans (David B. Evans)]

It's now 6 months after the MacPorts meeting in Slovenia. Wondering if we're in a position now to remove these old perl versions that have not had module support for quite a while. Most comments to this point have been in favor of removing them but we haven't heard anything about feedback from the meeting. It would be nice to be able to close this ticket.