[148570] trunk/dports/devel/subversion-perlbindings/Portfile

[Mojca Miklavec]

On 12 May 2016 at 14:44, Daniel J. Luke wrote:
> On May 11, 2016, at 2:16 PM, mojca at macports.org wrote:
>> subversion-perlbindings: add new subport subversion-perlbindings-5.24
>
> While this change is fine - it's not an openmaintainer port (and this wasn't a "broken port" issue), so I would have appreciated a note.

I'm really really sorry for not sending a notice upfront. (I'll try to
get better in communicating changes next time.)

The subversion-perlbindings itself wasn't broken, but in fact some
ports (p5.24-<something>) were broken because of a missing dependency
on subversion-perlbindings-5.24 and given that the change just *added*
a new subport rather than having any influence on the existing ones, I
treated this port in the same way as all other p5-<something> modules.
(I would actually forget about subversion-perlbindings if I didn't get
a report of broken ports from the buildbot.)

I didn't check right now, but I'm sure that we have a number of ports
in p5-<something> that have exactly the same "problem": they are not
openmaintainer and yet we have to change them unless someone is
willing to write software that will create a dependency tree and only
update those ports which are themselves openmaintainer or nomaintainer
(and no dependency may be no-openmaintainer either). Then ask
maintainers to add "5.24" to their ports, wait forever, do another
round of updates, ask maintainers of ports that were previously unable
to update their ports because dependencies were maintained and without
"5.24" etc, wait another round, do another round of updates, go to the
third layer of maintainers etc.

Asking maintainers to start adding 5.24 themselves *before* any port
has "5.24" is a pain because (at least in my case) I would need tens
of dependencies fixed first before being able to fix mine.

----------

A more serious question though (and it's not a rethorical one!). Let's
assume that we would already be using a single version of Perl *now*
and we would still be at Perl 5.22 (like we are). Someone would be
assigned the task to upgrade to Perl 5.24, including all the 1,5 k
dependencies that would need a revbump at least (many of which would
in fact be broken after the switch). Then again, maintainers could not
test their ports before all dependencies switch to 5.24. How exactly
would you envision dealing with no-openmaintainer ports in that case?

Mojca