How install p5-libapreq2 for perl 5.20?

[Daniel J. Luke]

On Sep 15, 2014, at 6:58 PM, Ryan Schmidt <ryandesign at macports.org> 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?

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

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

> * We also need a strategy for rebuilding every p5-YY port when a new version of perl is released (e.g. a reliable script to revbump each p5-YY port).

you said one existed already, and jmr sent one to the -dev list that has been used in the past.

> You've previously favored modifying MacPorts base to obviate the need to revbump each p5-YY port.

I have favored several future improvements to base to make the perl situation better - of course everyone wants to talk about/bikeshed them instead of thinking about the steps we can do /now/ to move to one perl5 port/one set of p5- ports and dramatically improve/simplify the perl situation in MacPorts immediately.

this discussion probably belongs on -dev.
--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+