Remove p5.8 and p5.10

Ryan Schmidt ryandesign at macports.org
Fri Aug 15 09:14:03 PDT 2014


On Aug 14, 2014, at 4:02 PM, Mojca Miklavec wrote:

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

I'm not sure what defining perl5.default_branch to 5.16 in the portgroup has to do with the idea of removing p5.8 and p5.10 ports. Currently perl5.default_branch is set to whatever perl the perl5 port is using, or 5.16 if the perl5 port is not installed.

replaced_by doesn't work (i.e. doesn't inform the user of available replacements via "port outdated") unless the port's revision (or version) is increased. The portgroup could do that too with a simple conditional "incr revision". This won't be noticed until the port is reindexed, but the port will be reindexed when the portfile is modified to remove 5.8 and 5.10 from perl5.branches.

Setting replaced_by and increasing the revision only helps upgrades. It is also necessary to prevent users from attempting to install the port outright. That's accomplished with a pre-configure block that generates an error. See the implementation in the obsolete-1.0 portgroup for example. And that deliberate error will of course cause every p5 module port to then appear to fail to build on the buildbot, which would be crummy to have to deal with for the year during which we would want to keep the replaced ports around.

We could think about an alternate solution in which we develop one single "obsolete perl modules" portfile whose sole purpose is to define non-installable subports for every one of the currently-existing p5.8 and p5.10 modules that we're going to replace. That way only that one port will cause a build failure on the buildbot, and updates to the real perl modules won't. We could then modify the perl5 portgroup to error out if perl5.branches contains 5.8 or 5.10 to ensure nobody adds new ports for these old versions.



More information about the macports-dev mailing list