Re: systemd-243-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux