Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

On 26/08/09 at 23:29 -0500, Manoj Srivastava wrote:
> On Wed, Aug 26 2009, Steve Langasek wrote:
> > On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
> >>         Given that devscripts,  lintian,  and the dev-ref
> >>  all advocate  or implement  +nmu\d+, and that debhelper and  cdbs look
> >>  at the hyphen for determining native vs non-native,  I have tried to do
> >>  so.  I think the proposed practice is strictly better  than not
> >>  specifying any conventions, and where possible, Ihave tried to stick to
> >>  best practices as documented in the dev-ref to base policy on.
> >
> >>         Having said that, there are a lot of packages that seem to still
> >>  use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this
> >>  policy change as a 'recommends', and letting lintian warn about the
> >>  version number.
> >
> > I don't agree that this is something that should be recommended.
> > Changing the convention for NMU versioning of non-native packages is
> > not necessary in order to correct the use of confusing version numbers
> > for NMUs of native packages.  If the dev-ref is recommending +nmuN for
> > non-native packages, then I think that's a bug in the dev-ref - a
> > common enough problem given the lack of a public process for dev-ref
> > change reviews.
> 
>         I think they changed that in a newer release than the one
>  referred to in the bug report I saw.

Yes. It was initially changed to +nmuN for both native and non-native
packages. But I recently saw that almost everybody was still using .N
for non-native ones, so I fixed dev-ref accordingly. (I don't think that
dev-ref should be used to change policy, it should document the current
pratice, which is +nmuN for native pkgs, and .N for non-native ones.)

> ,----
> |  Stable Security NMU's
> |    Version =~  m/\+deb\d\d.\d+$/
> |  Testing Security NMU's
> |   Version =~ m/\+debt\d\d.\d+$/
> `----
>         These last two do not have buy in from the security team, as far
>  as I can tell.

That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
3. etch is released with P 1.0-1.
4. A security bug is found in P.
5. An oldstable security upload is done for P 1.0-1+sarge1
6. S installs 1.0-1+sarge1
7. A stable security upload is done for P 1.0-1+etch1
8. S is upgraded to etch. P isn't upgraded: 1.0-1+etch1 << 1.0-1+sarge1
9. sarge reaches end-of-life, and is no longer supported
10. Another security bug is found in P
11. A stable security upload is done for P: 1.0-1+etch2

At this point, S won't auto-upgrade to O 1.0-1+etch2 (since 1.0-1+etch2
< 1.0-1+sarge1). S will keep the vulnerable version of P.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |