Re: binary NMUs and version numbers
Goswin von Brederlow wrote:
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
Adding the implicit '0' that dpkg assumes on versions ending in alpha
chars would solve both cases:
That is, 1.2-1~beta == 1.2-1~beta0 << 1.2-1~beta0+b1 << 1.2-1~beta1
That'd mean REJECTing uploads whose versions match
"[^0-9]+[a-z][0-9]+$" presumably.
^ ^
First + is literal, second + is "one or more". One should be escaped.
Which one? Depends whether it's a regexp or an eregexp... :-/
No, why?
Because 1.2-1~beta+b1 >> 1.2-1~beta1.
That regexp is rejecting uploads where there *isn't* a number before the
+. '[^0-9]\+[a-z0-9]+$' (as an eregexp) might be better.
A version matching "[a-z]$" has an implicit trailing 0
in dpkg version terms.
Not really; it just compares equally to the same string with any number
of trailing zeroes. Versions without an epoch don't have an epoch, but
they do compare equally to the same version with an epoch of zero.
Try:
] dpkg --compare-versions 'beta' eq '00:beta0000-000'; echo $?
for those playing along at home. Or
] dpkg --compare-versions '10' eq '010'; echo $?
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]$".
Err, the above regexp didn't match anything ending in a-z, no matter how
you construe it...
Cheers,
aj
Reply to: