On Fri, Aug 2, 2019, 11:39 Fabio Valentini <decatho...@gmail.com> wrote:
> On Fri, Aug 2, 2019, 11:33 Adam Williamson <adamw...@fedoraproject.org> > wrote: > >> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote: >> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit : >> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote: >> > > >> > > > Since these things are both the case, a simple 1:1 mapping from "-" >> > > > to >> > > > "~" (and even back) is exactly correct. >> > > > So I think the systemd.spec is doing exactly the right thing here. >> > > > >> > > > The only issue I see is the arbitrary (?) restriction that git tags >> > > > cannot contain the tilde character. >> > > > Or is that there for filesystem compatibility, because tags are >> > > > just files? >> > > >> > > git uses "~" for referencing commits relative to a commit identifier, >> > > see: >> > > >> > > >> https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em >> > > >> > > Hence they do not allow it in tag names, to avoid the ambiguity. >> > > >> > > I guess RPM is the outlier for using ~ the way it uses it, I don't >> > > think much other software does that. >> > >> > ~ is a debianism, introduced in rpm because some felt it was going to >> > satisfy uptream needs for irregular preversiob versioning >> > >> > what rpm likes, and pretty much all component management stacks like >> > and support, is pure series of numbers separated with dots, without the >> > -foo pre-version madness that breaks everywhere in slightly different >> > ways. >> > >> > Don't release anything that is not a series of numbers separated with >> > dots, no one ever managed to define anything else that works for >> > everyone (and many tried). >> > >> > The preversion in semver is basically "it will break right and left, >> > who cares, no one will use it". Written by idealists that forgot the >> > point of preversions is to be used and deployed so some testing is done >> > before final release. >> >> Hmm. I never really chipped into the ~ discussion, but it just occurred >> to me it intersects with a discussion I care quite a lot about: RPM >> version comparison. Especially RPM version comparison when all you have >> to deal with is a string that represents an RPM N(E)VR(A) somehow >> (that's 'name', 'epoch', 'version', 'release', 'arch'). >> >> This is a corner case quite a few of us run into (it can happen for >> e.g. when you're working off a fedmsg which just gives you a NEVRA >> string) and it has some surprising properties, like: there isn't really >> a 'good' standard way to do it. RPM doesn't expose this in its public >> APIs. The best way anyone seems to know of to do it in Python, for >> instance, is using `hawkey.split_nevra`...only hawkey is a bit weird, >> it's provided by libdnf and is not in pypi, which means running tests >> on code that uses it using standard stuff like tox-in-a-container is >> difficult. Also, DNF folks have suggested they want it to go away. >> >> You can split a N(E)VR(A) string into components quite easily and >> reliably with standard string manipulations, but comparing the >> components the way RPM does it is difficult to re-implement...and of >> course, the more weird rules like ~ we introduce, the harder it gets. >> >> Anyhow, it occurred to me to try out how hawkey.split_nevra handles >> this tilde scenario, and the answer seems to be "a bit oddly": >> >> >>> tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31') >> >>> releasenevra = hawkey.split_nevra('systemd-243-1.fc31') >> >>> releasenevra > tildenevra >> True >> >>> releasenevra.version >> '243' >> >>> tildenevra.version >> '243~rc1' >> >>> releasenevra.version > tildenevra.version >> False >> >>> tildenevra.version > releasenevra.version >> True >> >> So...basically, it thinks the entire NEVRA object you get from the >> string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object >> you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's >> correct. However, it thinks the version component of 'systemd-243~rc1- >> 1.fc31' is higher than the version component of 'systemd-243-1.fc31'. >> Which I believe is wrong, and also, it's a bit baffling, because if it >> thinks that, I don't understand how it gets to the (correct) conclusion >> that the entire tildenevra is lower versioned than the releasenevra, >> since the 'name' and 'epoch' ('systemd' and 0, respectively) are the >> same for both... >> >> Anyone see what I'm missing? >> > (snip) > You have to be careful with comparisons here. if the .version attribute is > just a string, then python will do just a string comparison (which is > sometimes wrong compared to RPM version comparisons). > > Fabio > Also, you can use rpm.labelCompare() from the RPM python bindings to check for version ordering, since rpm.labelCompare() gives you a total order over (epoch, version, release) string triples. It's easy to wrap that inside an "idiomatic" python NEVR class that has the desired ordering properties and overrides >,<, etc. correctly. I hope this helps. > -- >> Adam Williamson >> Fedora QA Community Monkey >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net >> http://www.happyassassin.net >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
