Remove p5.8 and p5.10

[Mojca Miklavec]

On Fri, Aug 15, 2014 at 6:14 PM, Ryan Schmidt wrote:
> 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.

One of the uses would be to make p5.8-foo replaced_by
p${perl5.default_branch}-foo, but in fact using perl5.default_branch
in regular ports is another issue.

> Currently perl5.default_branch is set to whatever perl the perl5 port is using, or 5.16 if the perl5 port is not installed.

I was actually thinking about a variable with a fixed value that could
be used in ports listed in ticket
    https://trac.macports.org/ticket/44405
If perl5.default_branch depends on user preference, it's probably not
suitable for this purpose.

But again, yes, that's a different issue.

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

I agree. A failure on the buildbot for any given perl module would be
a relatively bad idea.

I don't know how the buildbot works exactly, but I would really like
to see a way to avoid such failures. I really dislike build errors in
cases where a port is known not to work (let's say that it only works
on 10.9 or only with Carbon). I'm sure there must be a way to prevent
users from installing a "defunct" port while avoiding the build
failure on the buildbot.

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

I would prefer fixing the way absolete ports are handled on the
buildbot, but this "hack" would also be a feasible option. It would
require a bit of work, but it's doable.

Again, I don't think that worrying about how users would get rid of
perl 5.8 is really our concern at the moment. But it would be nice to
have this in place when trying to get rid of 5.12 and 5.16.

Mojca