#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