Re: binary NMUs and version numbers
Anthony Towns <aj@azure.humbug.org.au> 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
> whatever.
>
> -rw-rw-r-- 16 katie debadmin 2908273 May 2 2004
> pool/main/m/mutt/mutt_1.5.6.orig.tar.gz
> -rw-rw-r-- 16 katie debadmin 412082 Nov 17 10:17
> pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz
>
> It seems to result in rather large diffs, and I can't really see the
> benefit?
>
>> 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.
> Cheers,
> aj
MfG
Goswin
Reply to: