https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275167
--- Comment #22 from John Hein <jcfyecr...@liamekaens.com> ---
I think this can be closed now. The old port was deprecated and is now gone.
Dependent ports have been updated to point to the new port.
Note that comment 20 has not been addressed - separate bug.
(In reply to Palle Girgensohn from comment #17)
First let me say that I understand the position to force ports to use a newer
version in some cases and started thinking along the same lines in this case at
first.
I came down on the side of deprecating the older version mainly for the
following reasons:
(1) I don't know the ramifications of moving to a new update for all the
affected ports. I took a look, but I realized I don't know enough. For
example, for some of the ports that specify service-identity as a dependency, I
don't see a direct dependency. Maybe the service-identity dependency should
just be removed for some of these ports. If so, that's more correct - even
better than globally updating their dependency to a newer version.
(2) There is ('was' now) indeed a run-time conflict between some of these
ports. But, to be honest, most of these ports are not critical ports for the
global ports tree. I'm sure they are important to some, but I'm saying they
are not globally critical. To me, this indicates that we don't have to act
without having a full understanding of the ramifications. py-twisted is pretty
important, and after some analysis, it seems that it can be updated to
service-identity 23.1.0. But I don't have the time to analyze all the affected
ports - at least not to a confidence level where I am comfortable with forcing
them all to a new dependency version.
(3) The maintainers of the affected ports should be able to evaluate and have
time to weigh in on updates for their port.
Doing global updates to ports without maintainer feedback should be done
sparingly unless the changes are obviously correct and necessary for the
greater good.
I fully understand why one would want to do the sweeping patch. But this
didn't seem to rise to that level of emergency. Allowing maintainers some time
to review seems reasonable. Build failures are much less problematic than
run-time failures - the latter is harder to debug.
At the very least the maintainers of the affected ports should be explicitly
invited to review and given time to evaluate.
Generally, regardless whether we go the "deprecate" route or the "update all
affected ports now" route, we should invite all the affected maintainers to
evaluate how changes will affect their port (including whether the port really
does need a direct dependency on service-identity).
--
You are receiving this mail because:
You are on the CC list for the bug.
