Re: Clarification about special characters in version and some suggestions
Samuel Henrique <samueloph@debian.org> writes:
> I suggest making it more explicit by adding an example to it and
> explicitly writing the precedence of them, I did some tests with dpkg
> --compare-versions to confirm and found out that that is (n being a
> number):
> "~ - n + ." eg.: 1.0~0-1 < 1.0-0-1 < 1.0-1 < 1.0+0-1 < 1.0.0-1
Ideally no one should ever use 1.0-0-1, so I'm a little dubious about
including it, but otherwise having examples seems like a good idea.
> And when symbols are repeated (tilt becomes the outlier):
> "~~ ~ - -- n + ++ . .." eg: 1.0~~0-1 < 1.0~0-1 but 1.0--0-1 > 1.0-0-1 (and
> same for + and .)
Likewise here, 1.0--0-1 is something no one should use. I'm not sure it's
worth explicitly adding examples for duplicate symbols other than for ~,
which is the only place where I think this is useful or likely to come up.
(There is an exaple for ~~ already, but it may not be the easiest to
follow.)
> The other suggestion, which is related to the issue I reported to
> repology;
> What if the policy started stating (or be more explicit if it already
> states) that ~ and - areexclusive for pre-release versions like
> alpha|beta|rc and + and . are for modifiers that arepost-release, like
> dfsg e git snapshots?
I'm not sure that I understand. Policy explicitly states that ~ sorts
before any other character, so by definition it sorts earlier than the
number without ~ appended.
If you're saying that those characters should be reserved for specific
semantic purposes, I don't think that's a good idea. There are various
tricky versioning situations where one really needs to use the full
sorting capabilities. The intent is for these characters to be
functional, not to have any specific meaning in the version.
Also, "." isn't really a modifier in that sense. It's normally part of
the upstream version, and I wouldn't recommend a Debian packager add a
period to the version, since that's likely to be confusing. Generally we
restrict ourselves to using ~ and +. (Maybe it would be a good idea to
say that in Policy.)
Lintian already warns about using .dfsg instead of +dfsg. Possibly we
should say something about that in Policy as well, since .dfsg is almost
always wrong because 1.0.dfsg1 >> 1.0.1.
> The main idea I'm trying to chase is to make it formal that when parsing
> a package version one can always assume that any package with ~ or -
> before its last hyphen is packaging a version that is less than the
> "plain one" (the numeric part of it before the modifiers), and that it's
> the inverse for the + and . modifiers, in which the given package
> contains that "plain" version plus some other things/changes (dfsg or
> git).
With the caveat about ".", I think this is just a restating of the sorting
order, which is correct. That is the order in which the versions will
sort.
If you want to make a stronger assumption that a package with ~ or + is
based on an upstream release with that component removed, I think that
assumption may be too strong (for instance, it's violated by the +really
convention documented in Policy).
> I've also seen people setting up d/watch to deal with this and I believe
> it could be avoided by having it as a policy and changing uscan to
> follow it.
I'd have to hear more about the specific use case you had in mind. uscan
already supports @DEB_EXT@ and dversionmangle=auto, which I think does a
lot of what you want.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: