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 changes). 0.9.0 also addresses some other issues: https://github.com/nsqio/pynsq/releases/tag/v0.9.0 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 comparison. 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. QA: portlink (ok) 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 [1] 'reason' for MFH wants only one of: bugfix or security release, so this instead, I guess: MFH: 2021Q2 (bugfix) [1] https://wiki.freebsd.org/Bugzilla/TriageTraining
(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!
Maintainer reset.
Thanks for this PR, but since net/py-pynsq has been upgraded to 0.9.1 we can close it.