Re: binary NMUs and version numbers
Anthony Towns <firstname.lastname@example.org> writes:
> Goswin von Brederlow wrote:
>> 1.rc << 1.rc2 << 1.rc+b1
>> 1.2-1~beta << 1.2-1~beta2 << 1.2-1~beta+b1
> 1.2~beta-1 << 1.2~beta-1+b1 << 1.2~beta2-1
> Keeping the Debian revision simple is a Good Thing.
>> Adding the implicit '0' that dpkg assumes on versions ending in alpha
>> chars would solve both cases:
> That'd mean REJECTing uploads whose versions match
> "[^0-9]+[a-z][0-9]+$" presumably.
No, why? A version matching "[a-z]$" has an implicit trailing 0
in dpkg version terms. When adding a + that implicit 0 must be added
explicitly to preserve the ordering. With that rule there is no reason
to rstrict the version to exclude "[a-z]$".
>> Another case that should be considered is the existing use of + for
>> revisions of a cvs snapshot (e.g. mutt uses a + but always does so):
>> 1.2-20041208 "<<" 1.2-20041208+2 "<<" 1.2-20041208+b1
> Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the
> upstream version? Or "1.2-20041208-1", or "1.2+cvs20041208-1" or
> -rw-rw-r-- 16 katie debadmin 2908273 May 2 2004
> -rw-rw-r-- 16 katie debadmin 412082 Nov 17 10:17
> It seems to result in rather large diffs, and I can't really see the
>> There are 3 simple solutions to this:
>> 1. forbid + in debian versions and think of another character instead
>> doing the same (must be < '.')
> Actually, that doesn't work either -- otherwise a new maintainer
> version (x-y#1) compares less than an old NMU (x-y.1). For the same
> reason "= ." doesn't work.
Right, so a debian version may only be extended by characters that
compare > '.'. That should be noted somewhere.