perl5: change default perl from 5.16 to 5.22

[dbevans (David B. Evans)]

As mf2k has recently mentioned, as we come to the end of the year, its probably a good time to change the default perl from perl5.16 to perl5.22.

Tasks to accomplish:

• change the default variant of port perl5 to +perl5_22
• change the hardcoded fallback perl branch in the perl5 port group from 5.16 to 5.22
• update any ports that declare perl variants to use the perl5 port group without forcibly declaring the default variant. This will allow these ports' default variant to automatically follow that defined by the perl5 port group, simplifying future updates. At this point, I believe there are only two ports that need attention.

I realize that there are currently many ports left that depend explicitly on perl versions other than perl5.22 (#48365) but I don't see that as a gating task for executing this ticket. Of course, they will have to be updated before any further outdated perls can be removed and perhaps changing the default will provide an incentive to finish these updates.

Let me know if you have any comments or suggestions reguarding this proposal. Otherwise, I will go ahead and make the changes in the next few days. I've already made the changes in my local port repo and they appear to work well.

Ports that currently set the default perl variant forcibly (other than perl5) and don't use the perl5 port group:

• biblatex-biber (dports, openmaintainer)
• percona-toolkit (pixilla, openmaintainer)

[mojca (Mojca Miklavec)]

"unified" Perl port (preliminary)

[mojca (Mojca Miklavec)]

David, in order to avoid opening too many tickets I'm attaching my proposal for a perl5 port that unifies all perl5-related ports. I didn't add the patchfiles yet (there are tiny differences, so I would need to rename them first). It's not exactly related to the issue at hand, but what do you think?

Feel free to proceed with the rest of the changes needed to make 5.22 the default Perl.

(I used the name xperl5.x to avoid naming clashes while testing, but that should be changed to perl5.x of course.)

[neverpanic (Clemens Lang)]

Looks good to me. Thanks for doing this.

[mojca (Mojca Miklavec)]

I trusted David's research and copied everyone from this ticket to a somewhat related #50000 (feel free to unsubscribe if you are not interested in brainstorming about the future packaging of Perl).

[dbevans (David B. Evans)]

Replying to mojca@…:

David, in order to avoid opening too many tickets I'm attaching my proposal for a perl5 port that unifies all perl5-related ports. I didn't add the patchfiles yet (there are tiny differences, so I would need to rename them first). It's not exactly related to the issue at hand, but what do you think?

Feel free to proceed with the rest of the changes needed to make 5.22 the default Perl.

(I used the name xperl5.x to avoid naming clashes while testing, but that should be changed to perl5.x of course.)

Mojca, I think the idea of consolidating the current separate perl5.* ports into perl5 as subports makes sense and is in line with current practice in other port series. Of course, all but one of these will hopefully be removed in the not too distant future but we need to come to a consensus on exactly how that will be done.

Personally, taking a page from other perl managers, I would propose to add subports for the current unstable perl version, the current upstream git master (blead) and perhaps a generic alias to the current stable perl. One might call these perl5-stable perl5-devel perl5-blead. I think that this would be useful to users who are actually developing perl modules and would like to test against these versions without concern as to which version is stable, unstable, etc.

Also I think it would be appropriate for you to place yourself as the first maintainer rather than myself given your contributions in this area over the past year or so.

[dbevans (David B. Evans)]

Ok, I did it.

perl5 port and port group changed to use perl5.22 as the default rather than perl5.16 in r143599.

In addition, in r143602, I've incremented the revision on all the ports that use the perl5 port group to create variants since they will all now use +perl5_22 as the default variant instead of +perl5_16.

I've left biblatex-biber and percona-toolkit untouched since they are hard coded to use +perl5_22 as the default. However, I'd urge their maintainers to re-write these ports to use the perl5 port group so that they will automatically track any change in default perl that may occur in the future.

[danielluke (Daniel J. Luke)]

Replying to devans@…:

Mojca, I think the idea of consolidating the current separate perl5.* ports into perl5 as subports makes sense and is in line with current practice in other port series.

+0

Of course, all but one of these will hopefully be removed in the not too distant future but we need to come to a consensus on exactly how that will be done.

+1

Personally, taking a page from other perl managers, I would propose to add subports for the current unstable perl version, the current upstream git master (blead) and perhaps a generic alias to the current stable perl. One might call these perl5-stable perl5-devel perl5-blead. I think that this would be useful to users who are actually developing perl modules and would like to test against these versions without concern as to which version is stable, unstable, etc.

-1 we generally only provide 'latest stable' releases of software, and I don't think perl is special.

People developing modules against unstable perl or git master are not really the focus for macports.

The main problem, from my perspective, would be that we'd still have multiple sets of p5- modules (or the unstable/bleed ports wouldn't be all that useful).

[dbevans (David B. Evans)]

Replying to mojca@…:

David, in order to avoid opening too many tickets I'm attaching my proposal for a perl5 port that unifies all perl5-related ports.

I wouldn't worry about too many tickets. I think having multiple tickets that are each focused on a particular task or modification are preferable as it focuses the attention on the issue at hand and makes for easier reading (for me, anyway).

I'm going to close this ticket, since its original proposal has been completed and encourage you to move your additional proposal to a separate ticket for further consideration.

[dbevans (David B. Evans)]

Replying to dluke@…:

Replying to devans@…:

Mojca, I think the idea of consolidating the current separate perl5.* ports into perl5 as subports makes sense and is in line with current practice in other port series.

+0

Of course, all but one of these will hopefully be removed in the not too distant future but we need to come to a consensus on exactly how that will be done.

+1

Personally, taking a page from other perl managers, I would propose to add subports for the current unstable perl version, the current upstream git master (blead) and perhaps a generic alias to the current stable perl. One might call these perl5-stable perl5-devel perl5-blead. I think that this would be useful to users who are actually developing perl modules and would like to test against these versions without concern as to which version is stable, unstable, etc.

-1 we generally only provide 'latest stable' releases of software, and I don't think perl is special.

Well, we do often provide a -devel version of ports for unstable versions where it seems justified, particularly for the purpose of testing dependent software against them before the next stable release comes out. It would be nice to be able to test current modules against the upcoming changes before we switch to a new stable version that might cause breakage.

People developing modules against unstable perl or git master are not really the focus for macports.

I'm not sure why we should artificially limit our target audience. A number of upstream developers do test their modules against OS X and or provide OS specific features. It seems to me, the more people that use MacPorts the better.

The main problem, from my perspective, would be that we'd still have multiple sets of p5- modules (or the unstable/bleed ports wouldn't be all that useful).

This is true. In fact, after spending some time trying to keep modules up to date, I'm beginning to come around to the point of view that there has to be a better way. Adding and updating perl modules as ports is maintainer intensive and we don't have that many maintainers that are interested in doing it. Other perl managers such as cpan and perlbrew download and build modules and their dependecies on an on-demand basis from CPAN by merely referencing the name without having to explicitly add them as a port. Perhaps the idea of looking into leveraging one of these other managers to provide perl dependencies for our ports might be productive and could potentially relieve us of this onerous task. An idea for discussion in #50000 perhaps.

[mojca (Mojca Miklavec)]

Opening a new ticket would probably be better, but I committed r143612 now (followed by r143619, r143621, r143622). Please double-check for any errors that I might have overlooked and feel free to improve the portfiles. There should be absolutely no difference in functionality. If there is any difference, that's my bug, so please open a new ticket.

I hope that the majority of subports will be removed soon.

---

Yes, further discussions about packaging should go to #50000. (Discussions about packaging Perl 6 could just as well go to #60000 :)

[mojca (Mojca Miklavec)]

Replying to devans@…:

In addition, in r143602, I've incremented the revision on all the ports that use the perl5 port group to create variants since they will all now use +perl5_22 as the default variant instead of +perl5_16.

What I don't understand is the following:

• if users have foo +perl5_16 installed, they won't get foo +perl5_22 with an upgrade until we actually remove the perl5_16 variant (but they will have to rebuild the port for no benefit)
• buildbots will build the binaries (which is nice)

Wouldn't it be better to just touch those ports or force-build them on the buildbots?

[dbevans (David B. Evans)]

Replying to mojca@…:

Replying to devans@…:

In addition, in r143602, I've incremented the revision on all the ports that use the perl5 port group to create variants since they will all now use +perl5_22 as the default variant instead of +perl5_16.

What I don't understand is the following:

• if users have foo +perl5_16 installed, they won't get foo +perl5_22 with an upgrade until we actually remove the perl5_16 variant (but they will have to rebuild the port for no benefit)

An upgrade will rebuild the variant they currently have if available. An install will get the new variant. This assumes that perl5 is not installed with a different variant. If it is, then the port group will take perl5's variant as the default. If perl5 is not installed the port group now falls back to 5.22 (the buildbot case).

• buildbots will build the binaries (which is nice)

Wouldn't it be better to just touch those ports or force-build them on the buildbots?

Perhaps, but I'm not worried about conservation of revision numbers and I wanted to make the point that something new is going on.