On Sun, Mar 16, 2008 at 08:23:43PM +0900, Charles Plessy wrote: > Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit : > > > > This could also lead to a problem in very rare cases: If a program has > > the same version in stable and testing, and gets a security update, then > > they both get a similar version. For the example, say 1.2-5.1+sarge1 in > > stable and 1.2-5.1+etch1 in testing. Now the version in testing is > > lower than that in stable, because "etch" << "sarge" (which is why I > > didn't use current names, since "lenny" is, by chance, >> "etch"). > > then replacing, "sarge", "etch" and "lenny" by "debian3.1", "debian4.0" > and "debian5.0" would solve the problem permanently :)
I thought about this as well, but AFAIK we don't always know in advance what the version number of testing will be (if it's going to be a minor or major version increase). > By the way, is it necessary that the NMUs would not simply increase the > version number just as regular maintainer uplads would, given that it > can simply be detected otherwise ? NMUs should be as non-intrusive as possible. If the maintainer wants to use odd numbers for experimental versions, for example, an NMU shouldn't break that convention. That's why for non-native packages, the debian revision is incremented in a way that doesn't touch the maintainer's versioning scheme. As I proposed, we could do the same for native packages, by adding ".1" instead of "-0.1". This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc, but we're talking about native packages, which means we can expect upstream not to be so crazy. And if we can't expect that, we can enforce it by writing it in policy. ;-) For all practical purposes, adding ".1" really is "incrementing the version number", it's only not with the usual step for maintainer uploads. 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
signature.asc
Description: Digital signature
