Moving to One Perl

[Ryan Schmidt]

Discussion moved from macports-users. Previous thread:

https://lists.macosforge.org/pipermail/macports-users/2014-September/036386.html


On Sep 16, 2014, at 9:33 AM, Daniel J. Luke wrote:

> On Sep 15, 2014, at 6:58 PM, Ryan Schmidt wrote:
>> 
>> On Sep 15, 2014, at 5:13 PM, Daniel J. Luke wrote:
>>>> I realize the mod_perl.so would be specific to the perl version, that's why I suggested the hypothetical mod_perl2 port would have variants for choosing which perl version to use. 
>>> 
>>> so why would you pull it out of the p5.xx-mod_perl2 port and put it into mod_perl2+perl5.X ?
>> 
>> To make the p5-XX-mod_perl2 ports not conflict.
> 
> mod_perl is built against a specific version of perl. A hypothetical mod_perl2+perl5_10 would conflict with a hypothetical mod_perl2+5_12 the same way a hypothetical p5-10-mod_perl2 would conflict with a p5-12-mod_perl2, right?
> 
> What am I missing?

p5.10-mod_perl2 and p5.12-mod_perl2 can be active simultaneously (or at least that is the intention of the multiple perl versioned subports). Meanwhile it is only possible for a single version/variant of a port (e.g. mod_perl2) to be active at once.

> 
>> I haven't used mod_perl2 so I don't know if this makes sense.
> 
> maybe you're just suggesting a possibility and I was assuming you were dictating a strategy?

I was describing the two-step approach I was planning on following if and when I eventually got around to fixing the mod_perl2 port, and trying to explain why.

> 
>>>>> It would be better if we just supported one perl5 version.
>>>> 
>>>> I have no objection to that if someone wants to put in the effort to do it.
>>> 
>>> Other than consensus, what do we need to do?
>>> 
>>> We currently don't really give people a graceful (port upgrade) way of moving from one perl release to another.
>>> 
>>> I'm happy to make a branch where perl5 is perl5.20.0 and the perl5 portgroup is modified to not make subports (so p5-foo ports will just install like they used to), if that would be helpful.
>> 
>> I think we've discussed it before:
>> 
>> * We need a strategy for migrating users of the p5.XX-YY ports to the new p5-YY ports (e.g. using replaced_by).
> 
> why?
> 
> When we upgrade from one 'default' perl5 to another, we don't automatically install new p5-YY ports for the user now. It might be a nice thing to do - but it seems like not doing it wouldn't be any worse than what we do now.
> 
>> These replaced stub ports should stay around for a year to facilitate upgrades, yet should not cause every build of every p5-YY port to be perceived by the buildbot as a failure during that time (which is what would happen if the replaced stub ports are subports of the p5-YY ports). I suggested in another context earlier that we could have a single port whose sole purpose is to define subports for each of the currently-existing p5.XX-YY ports declaring them to be replaced by the corresponding p5-YY port. That port wouldn't need to be touched after being initially set up, so there would be only one buildbot failure report and updates of each p5-YY port can proceed unimpeded.
> 
> I would suggest that we just remove all of the p5-xx ports.

Why? Because one of the features we have advertised to users, and which they rely on, is that they can run "sudo port selfupdate" and "port outdated" and see which ports are outdated -- which ones have never versions available -- and run "sudo port upgrade outdated" to receive those updates.

If we just remove the p5.XX-YY ports (in other words, if we just remove the logic from the perl5 portgroup that causes those subports to be created), then users who have any of those subports installed will never know if and when they become outdated.