Bug 255307 - net/py-pynsq: update to 0.9.0 (fixes indirect conflict with math/py-matplotlib)
Summary: net/py-pynsq: update to 0.9.0 (fixes indirect conflict with math/py-matplotlib)
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
URL: https://github.com/nsqio/pynsq/releas...
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2021-04-21 16:02 UTC by John Hein
Modified: 2021-05-11 01:38 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (koobs)
jcfyecrayz: maintainer-feedback+
jcfyecrayz: merge-quarterly?


Attachments
[patch] update to 0.9.0 (2.88 KB, text/plain)
2021-04-21 16:02 UTC, John Hein
no flags Details
[patch] update to 0.9.0 [v2] (1.56 KB, patch)
2021-05-04 19:54 UTC, John Hein
jcfyecrayz: maintainer-approval? (koobs)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2021-04-21 16:02:02 UTC
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.
Comment 1 John Hein 2021-05-04 19:54:13 UTC
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)
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-05 02:29:08 UTC
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))
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-05 03:04:53 UTC
@John Can I ask what the conflicting tornado files are?
Comment 4 John Hein 2021-05-11 01:12:12 UTC
(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.
.
Comment 5 John Hein 2021-05-11 01:21:46 UTC
(In reply to Kubilay Kocak from comment #2)
Yes, I think this needs the same change on 2021Q2

MFH: 2021Q2 (conflict reduction)
Comment 6 John Hein 2021-05-11 01:27:27 UTC
(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
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-11 01:38:56 UTC
(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!