On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote: > [Adding bug #437392 to Cc, which deals with this issue for normal > NMUs, because I'm making a suggestion about them.] > > On Sat, Mar 15, 2008 at 11:52:55PM +0000, Adam D. Barratt wrote: > > devscripts 2.10.19 (soon to be uploaded) will modify the behaviour > of > > "debchange --nmu" to version an NMU of a native package as X+nmu1 > rather > > than the current X-0.1. > > Good idea. Even better, IMO, would be to use a system which is in > line with non-native packages. How about this rule: [using X.1] > IMO this solution is slightly better than +nmu1, because it makes > versions of native and non-native packages more uniformly mangled. > However, any solution is better than no solution. :-)
That does seem the most logical suggestion thus far. As .19 fixes a couple of regressions I'd like to get it uploaded soon so may stick with +nmu for the moment (as you say, it's still better than -0.1). [...] > > It has been > > suggested that either one of +s1 / +sec1 / +security1 or <release>1 > > should be used to avoid the issue. > > > > The main difficulty with the latter from the point-of-view of adding > > support to debchange is that there's no easy way of mapping a changelog > > distribution (e.g. "stable") to a release name, particularly as both > > stable and oldstable updates may have "stable" as the last distribution > > to which the package was uploaded. > > So the problem is that debchange is unable to know the version should be > "stable"? Or is the problem that versions may collide when oldstable > has a security update, and stable needs one as well? The problem is that the security team want to use version numbers such as "Xetch1" or "Xsarge1" and these can't reliably be deduced simply by looking at the package. If one takes the case of a package in etch or sarge that has not yet had a security update, how would dch know whether to use sarge1 or etch1 in the version number? The most recent changelog entry for both packages would be for "stable". Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
