Nathanael Nerode <[EMAIL PROTECTED]> writes:
> I was surprised to discover that the standard rules for Debian
> revision numbers
> (maintainer revisions contain no dots;
> source NMUs contain one dots;
> binary NMUs contain two)
> are not in Policy, but only in the Developer's Reference.
>
> This seems like a perfect example of a place where policy should follow
> practice; it would be supremely annoying and worthy of a serious bug
> if these revisioning rules are not followed. It's already checked in
> NM!
>
> Should a policy patch be created?
Since common practice for NMU, binNMU and security versions are
flawed, as in they don't sort right with dpkg --compare-versions, I
would rather see a new scheme be made policy.
Currently versions sort the following way:
1.2-3
1.2-3sarge1
1.2-3.0.1
1.2-3.1
As you can see the binNMU sorts after the security release while it
should be before it.
I suggest one of two alternative schems for binNMUs:
1.2 -> 1.2-0b1
1.2-3 -> 1.2-3b1
1.2-3+cvs -> 1.2-3+cvs0b1
1.2-sarge1 -> 1.2-sarge1b1
1.2sarge1 -> 1.2sarge1-0b1
In words:
- no debian revision: add -0b1
- debian revision ends in digit: add b1
- debian revision ends in letter: add 0b1
In the same spirit security releases could use s0.sarge.1 to avoid the
same problem in case of a future releas starting with 'a'.
The other scheme would be to declare a special char '#' that sorts
lower than everything but \000 and '~'.
1.2-3~pre1
1.2-3
1.2-3#1
1.2-3sarge1
1.2-3.1
This would require a dpkg, apt and dak change and could only be used
post etch. But it looks much better than the other scheme.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
