[MacPorts] #67830: perl5 @5.34 +perl5_36: cannot install perl modules

[MacPorts]

#67830: perl5 @5.34 +perl5_36: cannot install perl modules
------------------------------+--------------------
  Reporter:  NorthboundTrain  |      Owner:  (none)
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:
Resolution:                   |   Keywords:
      Port:  perl5            |
------------------------------+--------------------

Comment (by ryandesign):

 `cpan2port` is how you would create ports for new perl modules. That's not
 what's needed here. The ports for the perl modules already exist, they
 just don't list 5.36 as an available version.

 For any change to MacPorts, it's our hope that a contributor would test
 the change on their own system first before contributing it. So to add
 perl 5.36 support to a port like p5-file-copy-recursive, you would edit
 [browser:macports-ports/perl/p5-file-copy-recursive/Portfile the
 Portfile], add 5.36 to the end of the `perl5.branches` line, verify it
 builds, passes any available tests, and generally works, and send a pull
 request with that change. However, p5-file-copy-recursive depends on five
 other p5 modules; they would each need perl 5.36 added to them first. They
 may each have other dependencies, and so on. The perl ecosystem has a
 tendency to be composed of a zillion small interdependent modules. To
 identify all of the Portfiles that p5-file-copy-recursive depends on, you
 could use a command like this:

 {{{
 port -q file rdepof:p5.34-file-copy-recursive | grep /p5-
 }}}

 I get a list of 24 files. You could add 5.36 to the `perl5.branches` line
 in all of them, verify they all build and work, and submit the batch of
 changes as a pull request. The maintainers of the ports will be notified.
 I found five distinct maintainers across that collection of 24 ports. The
 maintainers would then approve or reject the change, or the change can be
 merged after 72 hours if maintainers do not respond.

 In the past, because we have nearly 2,000 perl module ports, and
 individually testing small batches is tedious and nobody volunteered to do
 that work, the entire batch of 2,000 perl module ports was updated to add
 a new perl version simultaneously without testing any of it first. If
 that's how we want to handle it again this time around we can but it
 causes a number of problems.

 First, somebody has to write a script to add 5.36 to each perl module's
 `perl5.branches` (or find someone's previous script that did that) and
 commit it. The resulting modifications have to be inspected carefully
 before committing. We have in years past inadvertently committed syntax
 errors or other mistakes at this point because the script did not
 anticipate some slightly nonstandard Portfile construction. You should be
 able to look through the git commit history or Trac ticket history to find
 previous perl version updates.

 Normally, any commit will automatically schedule builds of any ports that
 need to be built on the buildbot, for each builder. We currently have 17
 builders which would be about 34,000 builds scheduled. The buildbot
 software is not designed to accommodate anywhere near that many pending
 builds and this grinds the buildmaster to a complete standstill of 100%
 CPU usage and unresponsiveness. It then falls to the buildbot
 administrator (me) to manually cancel all of these builds (just cancelling
 the builds can take hours) and load the list of desired builds into a
 separate script that schedules them in small batches over the course of
 the next several weeks, which is probably about how long it would take to
 attempt to build them all. It is therefore appreciated if such a mass
 update commit can be coordinated with me so that I can shut off the
 buildbot commit notifications beforehand.

 And then there's the problem that since the builds were never tested, some
 of them may fail. New perl versions are usually highly compatible with
 older ones so this is not usually a problem, however there have been
 notable exceptions like perl 5.26 which removed `.` from `@INC` which
 broke quite a few modules which had to be identified and fixed manually.
 Since this might also be the first time the module has been built for any
 perl version since the last time a perl version was added to it, a build
 might fail for reasons unrelated to the perl version such as an
 incompatibility with a new version of macOS or Xcode.

 And when a port is fixed, that does not automatically schedule new build
 attempts for any ports that depended on that formerly-broken port. Someone
 either has to remember to do that manually, or else we don't do builds
 (and thus don't provide archives) for some ports that we should be able to
 build.

 Personally I favor the bit-at-a-time approach since it avoids those
 problems. It's what we use for python module ports and it seems to work
 there.

-- 
Ticket URL: <https://trac.macports.org/ticket/67830#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS