On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson 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 (decathorpe@xxxxxxxxx) 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... My guess would be that release.version is just a string, and doesn't override the __lt__. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
