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

Clarification about special characters in version and some suggestions



Hello team,

I was writing this bugreport for repology today[0] and decided to re-read
something in d-policy that was never very clear to me.

I'm gonna try to be verbose to try to make myself more clear.

5.6.12. Version[1]
It talks about how the characters ". + - ~" are evaluated both for upstream_version
and debian_revision:
"The lexical comparison is a comparison of ASCII values modified so that all the
letters sort earlier than all the non-letters and so that a tilde sorts before
anything, even the end of a part."

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

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 .)

The general idea being that tilts and dashes constitutes a version lesser than
of just using the plain number, and + and . constitutes a higher version than
of just the number (1.0+1-1 is bigger than 1.0-1).

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?

The policy might already define this but I couldn't find it, the closest to it
was this side note[2].

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).

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 understand that this is already the way most people use them[3], but I
believe having it in the policy and as a lintian warning would help putting
everything in shape.

Thanks for reading all of this, what are your thoughts?

Regards,

[0] https://github.com/repology/repology-updater/issues/966
[1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
[2] https://www.debian.org/doc/debian-policy/ch-controlfields.html#id22
[3] https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F

--
Samuel Henrique <samueloph>

Reply to: