How install p5-libapreq2 for perl 5.20?

[Ryan Schmidt]

On Sep 15, 2014, at 5:13 PM, Daniel J. Luke wrote:
> On Sep 15, 2014, at 5:28 PM, Ryan Schmidt wrote:
>> On Sep 15, 2014, at 8:58 AM, Daniel J. Luke wrote:
>>> 
>>>> For the first iteration, I would do nothing special. I would let each subport install those files, which would make the subports conflict with one another. That's not desirable, but better than the current unworkable situation.
>>>> 
>>>> As a second iteration, I would try removing those files from the p5.*-mod_perl2 subports, and put only those files back into a mod_perl2 port. I assume mod_perl.so requires the rest of the perl-version-specific files, so that port would have perl5.* variants which depend on the corresponding p5.*-mod_perl2 port.
>>> 
>>> that mod_perl.so is version specific (ie, it would be different for each of the sub-ports and so it can't be pulled into one common port). The sub-ports would just have to be marked as conflicting.
>> 
>> 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.

I haven't used mod_perl2 so I don't know if this makes sense. But for example p5.16-html-mason depends on p5.16-libapreq2 which depends currently on mod_perl2 and which we're proposing to change to depending on a new p5.16-mod_perl2. How is libapreq2 used? How is html-mason used? How are any of the other ports that depend directly or indirectly on mod_perl2 used? Do they *all* require that the actual mod_perl.so module be present and loaded into a functioning Apache server or is that incidental for some of them? I haven't made a full list of the ports that eventually depend on mod_perl2 and I don't know what they do so I can't answer this. But if there exists a port that eventually depends on mod_perl2 that doesn't actually need the mod_perl.so Apache module then it makes sense to allow the user to select which version of perl they want to use it with, and that's most easily enabled by ensuring that p5.XX subports do not conflict with one another.


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

* 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've previously favored modifying MacPorts base to obviate the need to revbump each p5-YY port. I still do not understand how that would be accomplished, so if you still favor that approach, perhaps you could discuss your concrete ideas for what would be changed in base to make this work. You also had a proposal for modifying the revision in the perl5 portgroup, which had some cosmetic consequences that I wasn't pleased with and would still require changes in base regarding the reindexing of ports.