[MacPorts] #50000: perl5: improve / reimplement packaging

[MacPorts]

#50000: perl5: improve / reimplement packaging
-----------------------------+--------------------------------
  Reporter:  mojca@…         |      Owner:  macports-tickets@…
      Type:  enhancement     |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:
Resolution:                  |   Keywords:
      Port:  perl5 perl5.22  |
-----------------------------+--------------------------------

Comment (by dluke@…):

 Replying to [comment:9 mojca@…]:
 > The fact is that a whole lot of ports depend on working perl. You don't
 notice it now because things keep working. A trivial problem with the new
 version of Perl could leave a great portion of MacPorts broken.

 I don't see how having multiple versions of perl around makes this better.

 > We are not talking about perl5.8, but about two versions at most (at the
 moment that would be perl5.22 and perl5.24).

 It seems really silly to do this just because we can't test / someone
 can't just upgrade a local perl, revbump modules, and fire off a script to
 validate them/find broken ones.

 > > Adding 'automatically' added versions to p5- ports also adds a bunch
 of (possibly broken) ports that will likely not be tested by maintainers.
 >
 > You mean mostly tested by `nomaintainer`? :)

 I'm just pointing out that the proposal keeps multiple perls around
 because it's too hard to test while at the same time introducing an
 automatic change that creates a bunch of untested ports.

 > There are soooooooo many perl (sub)ports that it's literally impossible
 to wait for maintainers to upgrade them individually.

 We really should be autogenerating Portfiles for all of CPAN (or hacking
 in support in base for cpan-managed installs for all perl modules).

 > And unless we provide means to easily test a new version of Perl, even
 those willing to do the testing won't be able to (I'm unable to test a few
 perl modules I maintain without updating tens of other modules first; we
 would end up in a deadlock).

 If the testing is automated, one developer can identify problematic ports.

 If there's more than one developer who is actually going to work on it - a
 private branch (or private "local" repo) would work well.

 > In any case I'm sure that switching to a single version without adding
 more functionality to the base (or to some external tools like buildbot)
 would be even more devastating than it is now.

 It simplifies things, which I believe makes solving the remaining problems
 more tractable. It's true that it doesn't fix all of the problems we have
 with perl (although it does fix a bunch of them).

 > And without testing we wouldn't be able to report problems upstream.

 one 'supported' perl version doesn't equal no testing.

 two 'supported' perl versions doesn't equal testing.

 > > I think we would be better off working on automation to run p5 port
 test suites to make it easier to validate ports and fix (or abandon) them
 >
 > Writing tools to simplify testing would certainly be of enormous added
 value. This is one point where I fully agree.
 > (Someone just needs to start contributing the code ...)

-- 
Ticket URL: <https://trac.macports.org/ticket/50000#comment:11>
MacPorts <https://www.macports.org/>
Ports system for OS X