[MacPorts] #50000: perl5: improve / reimplement packaging
noreply at macports.org
Tue May 31 06:55:18 PDT 2016
#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>
Ports system for OS X
More information about the macports-tickets