Re: Add Debian revision number standards to policy?

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Nathanael Nerode <neroden@twcny.rr.com> 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