#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