mod_perl2: add variants +perl5_18 +perl5_20

[dbevans (David B. Evans)]

mod_perl2 can only be built for one version of perl at a time and currently uses the default perl5.16. This restricts its dependents to perl5.16 as well since they must match.

An enhancement would be to add variants to optionally support perl5.18 and perl5.20 possibly use PortGroup active_variants or some other mechanism in the dependents to ensure that they are using the same perl version.

[danielluke (Daniel J. Luke)]

yet another issue that would be fixed by just having one good perl5 version (upstream's current stable version) in MacPorts

[mojca (Mojca Miklavec)]

Should we add mod_perl to the list of "affected" ports as well?

[mojca (Mojca Miklavec)]

add variants to support multiple perl versions to mod_perl2

[mojca (Mojca Miklavec)]

I attached a patch. Is anyone willing to test it?

On a related note, I would suggest to revert r132515 (#42582) or maybe add some require_variants after this ticket is closed. (The module will keep failing on the buildbot anyway, even if p5.20-libapreq2 will work on users' computers with perl5_20 variant enabled for mod_perl2.)

Also, we should start the transition to switch the default Perl. I don't consider the few remaining modules that miss support for 5.20 to be showstoppers.

[dbevans (David B. Evans)]

Replying to dluke@…:

yet another issue that would be fixed by just having one good perl5 version (upstream's current stable version) in MacPorts

Agreed but ...

[dbevans (David B. Evans)]

Replying to mojca@…:

Should we add mod_perl to the list of "affected" ports as well?

No, it does not build with perl5.16+ and IMO is not worth the effort to coax back to life. See #46764.

[dbevans (David B. Evans)]

Replying to mojca@…:

I attached a patch. Is anyone willing to test it?

Yes, I'll give it a try either this evening or tommorrow and see how it fares.

Also, we should start the transition to switch the default Perl. I don't consider the few remaining modules that miss support for 5.20 to be showstoppers.

This is OT for this ticket but I think we need to stabilize at the perl5.16 level before trying to move on.

Some issues remaining:

• fix issues that restrict some ports to perl5.16 such as this one
• remove 5.8-5.14 support/variants in perl5
• remove perl5.8 through perl5.14, now largely useless without extension module support.

Perhaps a good point to switch would be when 5.22 is released. Is there a target release date?

[mojca (Mojca Miklavec)]

Replying to devans@…:

Replying to mojca@…:

Also, we should start the transition to switch the default Perl. I don't consider the few remaining modules that miss support for 5.20 to be showstoppers.

This is OT for this ticket but I think we need to stabilize at the perl5.16 level before trying to move on.

What do you mean by stabilize?

Some issues remaining:

• fix issues that restrict some ports to perl5.16 such as this one

But this one is not a case where the port wouldn't work with 5.20. It's just that it won't work with multiple versions at once. And it will probably never work with multiple versions, even if we support 5.20.

• remove 5.8-5.14 support/variants in perl5
• remove perl5.8 through perl5.14, now largely useless without extension module support.

Removing perl5.8-5.14 can be done quickly and independent of everything else. And it's not really a showstopper in any way. (Even if those four ports would remain, it's not really a problem.) We just need to make sure that removing support for variants 5.8-5.14 won't break the graveyard ports.

Perhaps a good point to switch would be when 5.22 is released. Is there a target release date?

Are you suggesting a switch to 5.20 or 5.22?

I don't know if there are any target release dates, but if you look at ​http://www.cpan.org/src/README.html you'll see that for the last four to five years the versions 5.12-5.20 have always been released in May (5.12 in mid April). And 5.19.x is released on 20th each month. I would expect 5.22 to be released around 20th May.

[dbevans (David B. Evans)]

Replying to mojca@…:

Replying to devans@…:

Replying to mojca@…:

Also, we should start the transition to switch the default Perl. I don't consider the few remaining modules that miss support for 5.20 to be showstoppers.

This is OT for this ticket but I think we need to stabilize at the perl5.16 level before trying to move on.

What do you mean by stabilize?

I mean, that the there are issues with the current state of the perl ports that I would like to see addressed before moving on. I listed a few.

Some issues remaining:

• fix issues that restrict some ports to perl5.16 such as this one

But this one is not a case where the port wouldn't work with 5.20.

I don't believe this has been proven. I'm still testing.

• remove 5.8-5.14 support/variants in perl5
• remove perl5.8 through perl5.14, now largely useless without extension module support.

Removing perl5.8-5.14 can be done quickly and independent of everything else. And it's not really a showstopper in any way. (Even if those four ports would remain, it's not really a problem.) We just need to make sure that removing support for variants 5.8-5.14 won't break the graveyard ports.

So why not do it before moving on? No need to leave old issues open.

Perhaps a good point to switch would be when 5.22 is released. Is there a target release date?

Are you suggesting a switch to 5.20 or 5.22?

Again for stability (perl known to work well), I would switch the default from 5.16 to 5.20 when perl 5.22 is released. People who want to work with the latest and greatest can use 5.22 if they want. Then I would move the default version one step at a time as each new stable version is released.

If you want to discuss this further, please continue the discussion on macport-devel list. The issue of switching default versions of perl, while a valid issue, is off topic with respect to this ticket. Lets not confuse the issue at hand.

Thanks.

[dbevans (David B. Evans)]

The proposed patch works for me, Mojca.

mod_perl2 successfully builds for all 3 variants, locally and on the buildbots and the resulting modules test successfully when used with an Apache 2 server using both simple Perl CGI scripts and custom Perl response handlers.

Committed in r132669, maintainer timeout, with revbump to force build of variant based version.