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>
