Remove p5.8 and p5.10

Mojca Miklavec mojca at macports.org
Thu Aug 14 14:02:53 PDT 2014


On Thu, Aug 14, 2014 at 5:45 PM, Ryan Schmidt wrote:
> If we aren't quite ready to tackle "one perl" yet, we could still improve the situation slightly by removing all p5.8 and p5.10 modules. We wouldn't have to bother fixing some perl 5.8- and 5.10-specific issues, and it would be fewer subports for maintainers to test and for buildslaves to build.

I support the idea of removing modules for 5.8 and 5.10. We could
remove more, but we didn't quite get away from 5.12 yet.

> The question is how should we go about that. It would be straightforward to just remove 5.8 and 5.10 everywhere it is found in a perl5.branches line, but if any users still have those old modules installed, they would never receive notification that they should upgrade to newer perl versions to continue to receive updates. This is the de facto solution we are using for python modules as well. It might be cleaner to use the replaced_by mechanism to replace these older modules with newer counterparts, but that would be more work. Thoughts on whether that's necessary?

It might not be strictly needed for 5.8, but it would be very nice to
have it when we remove 5.12, so we might just as well implement it
now.

I'm not saying that I know how to implement it, but one option would
be to simultaneously do the following:
- remove 5.8 and 5.10 from all perl modules (can be scripted)
- define perl5.default_version in the PortGroup to 5.16
- automatically generate p5.8-foo and p5.10-foo subports using
"replaced_by p${perl5.default_version}-foo" mechanism (don't generate
those subports in case that a port has 5.8 and/or 5.10 in
perl5.branches)
- make sure that p5.(8|10)-foo doesn't generate a build failure on the
buildbot, that it doesn't pull in any dependencies and that it
processes fast

The idea would be that everything would be implemented in the
PortGroup while the ports themselves would only have to remove the
obsolete versions.

> Later we could remove perl5.8 and perl5.10, though at present some ports still depend on them:

I don't know rpm ports, but the existence of perl5.8 and 5.10 isn't as
much of a pain as all those thousands of modules. So indeed it doesn't
hurt if those ports are removed later.

Mojca


More information about the macports-dev mailing list