[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: - An NMU will add an extra item to the version number, which starts counting at 1. - When a new upstream version of a non-native package is uploaded, the debian revision is set to 0, and the extra item is added to that. This means that non-native NMUs will get the same versions as they always did, while native packages go from "1.8" to "1.8.1", for example. For native packages, it's impossible to package a new upstream version, because there is no upstream. 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. :-) > Whilst looking at this change, the question arose of what format > security uploads of native packages should use, both in general and > specifically when debchange's --security option is used. > > Currently, debchange will produce a version number of X-0.1 in such > cases which suffers from the problem described above. 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? That doesn't make sense, because the version will have increased in unstable (by then stable) at the time the oldstable (at that time stable) update was made. I'm a bit confused by the problem. However, I do see a problem with +s1 if +nmu1 is used: +s1 sorts after +nmu1. This means that this versioning can no longer be used if an NMU is needed after a security update. In particular, suppose: - The package version is 1.3 in all distributions. - A security issue is found. - 1.3+s1 is uploaded to stable and testing. - The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable. - Some time passes, and the package is about to migrate to testing. - Migration fails, because 1.3+nmu1 << 1.3+s1. This problem does not occur if 1.3.1 would be used for the normal NMU (to unstable). > After some discussion amongst the team on IRC we decided we'd be > happiest following either a request from the security team or a > consensus view (or as close to a consensus as -devel ever gets :-). I think using the rules I proposed above for normal NMUs, and +s<number> for security NMUs would be best. However, I might misunderstand the problem. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature