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 | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
