#49982: perl5: change default perl from 5.16 to 5.22 -----------------------+---------------------- Reporter: devans@… | Owner: devans@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: perl5 | -----------------------+---------------------- Comment (by devans@…): Replying to [comment:7 dluke@…]:
Replying to [comment:5 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 of other ports 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. -- Ticket URL: <https://trac.macports.org/ticket/49982#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X