Re: Add Debian revision number standards to policy?

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

Steve Langasek <vorlon@debian.org> writes:

> On Mon, Nov 21, 2005 at 03:23:17PM +0100, Goswin von Brederlow wrote:
>> 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:
>
> A little late, I think; this was discussed something like a year ago on
> debian-devel, and the conclusion was to use +b<num> for binNMUs.
>
> And this has been implemented in dak, sbuild, and wanna-build as of last
> week.

The discussion also includes changing security versions to +s... to
actualy fix the sorting problem:

1.2-3
1.2-3sarge1
1.2-3+b1
1.2-3.1

The change to +b1 is only half the problem, the problem of the DAK to
recognise binNMUs. It does not change the problem with security
updates not getting installed.

MfG
        Goswin