Created attachment 224333 [details]
[patch] update to 0.9.0
Update py-pynsq to 0.9.0
0.9.0 now supports tornado > 5
This is important for playing well in the ports tree. It avoids
the problem of, for example, py-matplotlib depending on www/py-tornado
(currently 6.1) and py-pynsq depending on www/py-tornado5 (5.1.1).
These two tornado versions currently install conflicting files,
so this effectively prevents users from installing py-pynsq when
py-matplotlib is installed. There may be other similar examples
of dependency issues.
tornado6 & tornado5 might be able to co-exist, but I suspect that
would be a lot harder to implement (probably requiring leaf port
0.9.0 also addresses some other issues:
In addition to the tornado support update, the most notable changes
are IPv6 support and improved RDY handling.
Note regarding PORTVERSION / DISTVERSION:
When this port was updated to 0.9.0b1, it should have used DISTVERSION
instead of PORTVERSION.
This would have generated a PORTVERSION of 0.9.0.b1. It seems
upstream intended b1 to mean beta #1 (rather than a "later" minor
update to 0.9.0). 0.9.0.b1 is better for package versioning
Now that we want to update to 0.9.0, version comparison thinks
0.9.0b1 is later than 0.9.0
Address this by using DISTVERSION=0.9.0 so the fetch gets the
right version - and because 0.9.0<0.9.0b1, set PORTVERSION=0.9.0rel
which evaluates to later than 0.9.0b1. This is better than using
a permanent PORTEPOCH bump.
% pkg version --test-version 0.9.0 0.9.0b1_1
% pkg version --test-version 0.9.0 0.9.0.b1_1
% pkg version --test-version 0.9.0rel 0.9.0b1_1
The porter's handbook currently documents this situation fairly well.
See section 5.2.2, particularly example 5.4 and 5.5.
I appreciate the subtle distinction between DISTVERSION & PORTVERSION (pre-release designators such as alpha, beta, etc. vs. post-release patch levels) a wee bit more after dealing with this particular case. I'll think twice before just updating PORTVERSION for a port update in the future since every upstream will apply versioning per its own (sometimes not well thought out) scheme.
Created attachment 224666 [details]
[patch] update to 0.9.0 [v2]
Reworked patch to avoid DISTVERSION & PORTVERSION defined at the same time. It worked fine that way, but the handbook (& portlint) frown on that.
So tweak the patch to specify GH_TAGNAME=v0.9.0 and PORTVERSION=0.9.0r. The latter is for the same reason mentioned for the first patch: to be "greater than" 0.9.0b1 without restoring to PORTEPOCH. I used 'r' instead of 'rel' just because portlint didn't like the latter. But the meaning for the 'r' is that it is the real 0.9.0 release (instead of the "b1" beta).
Again if the update to the 0.9.0b1 beta had used DISTVERSION as it should have, this would not be needed and the update to 0.9.0 (using PORTVERSION or DISTVERSION, although I think the latter is better generally) would have correctly been "0.9.0 > 0.9.0.b1".
For 0.9.1 (or some later release), I would use DISTVERSION. That future update can go back to DISTVERSION + DISTVERSIONPREFIX=v and drop GH_TAGNAME, or continue to use GH_TAGNAME + DISTVERSION without DISTVERSIONPREFIX. Both seem reasonable.
poudriere (ok - py38, stable-11/amd64)
Thanks John. Should this be merged to quarterly? If so please set merge-quarterly flag to ? with comment:
MFH: <branch> (<reason)>
else, set merge-quarterly to - with comment:
MFH: No (<reason))
@John Can I ask what the conflicting tornado files are?
(In reply to Kubilay Kocak from comment #3)
'pkg register' complained about this:
pkg-static: py37-tornado5-5.1.1 conflicts with py37-tornado-6.1 (installs files into the same place). Problematic file: /usr/local/lib/python3.7/site-packages/tornado/__init__.py
But I don't think that's the only conflict. At a quick glance at file listings also: tornado/platform/twisted.py, tornado/process.py, tornado/queues.py, and more. Dozens it seems.
(In reply to Kubilay Kocak from comment #2)
Yes, I think this needs the same change on 2021Q2
MFH: 2021Q2 (conflict reduction)
(In reply to John Hein from comment #5)
It looks like  'reason' for MFH wants only one of: bugfix or security release, so this instead, I guess:
MFH: 2021Q2 (bugfix)
(In reply to John Hein from comment #6)
The list is not exhaustive, only providing (common) examples for bugfix and security releases. I'll add notes to this effect, thanks!