[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 mojca@…):

 Replying to [comment:7 dluke@…]:
 > That is a lot of effort (for multiple simultaneous perl version
 installs) seemingly mostly because we're afraid of breaking things on
 upgrade

 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 think there is other benefit from keeping unsupported versions
 around).

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

 > 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`? :) There are soooooooo many perl
 (sub)ports that it's literally impossible to wait for maintainers to
 upgrade them individually. 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). 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.

 You probably do realise that if we will in fact support just a single
 version of perl, those "automatically added" will just become
 "automatically revbumped" and receive equally "zero" testing from
 maintainers?

 In case of changes like r148570 (which I admit should be done with more
 care on my side and I'm sorry for that), you would get a notice a few days
 in advance that things are going to change, but if perl5.26 was
 incompatible with your port, the revbump would actually break the
 functionality of the port (rather than just add a broken submodule that
 wouldn't be used by anyone). We could wait for a while, but I'm sure we
 wouldn't be able to wait for each and every of the thousands of ports to
 be tested. And without testing we wouldn't be able to report problems
 upstream.

 > 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:9>
MacPorts <https://www.macports.org/>
Ports system for OS X