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@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?
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