[MacPorts] #49982: perl5: change default perl from 5.16 to 5.22

[MacPorts]

#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