On Mon, Mar 17, 2008 at 04:46:54PM +0100, Vincent Danjean wrote: > Bas Wijnen wrote: > > Ok, that makes sense. However, with +nmu1, there still is the problem > > of how to name security uploads. With +s1, they sort after +nmu1, which > > I think is wrong. > > > > But we're talking about uploads to stable and testing anyway, so the > > +etch1 and similar version extensions are used. Do we want to solve the > > bug that they can have incorrect order? They should at least start with > > +X, where X is >> 'b' and << 'n', if they want to sort correctly with > > respect to binNMUs and source NMUs. > > I did not see any comments about Raphael's proposition (that seems better > to me): > > Raphael Hertzog wrote: > > It's possible, you just have to put the increment number before the > > "type" of upload: > > - +c0.nmu (non maintainer upload) > > - +c1.sec (security upload) > > - +c2.su (stable update) > > > > Unfortunately "+0.nmu" sorts before "+b1" so I had to put "+c0.nmu" so > > that binnmu sort lower. And "c" could mean "change" or "external change".
I don't really like the c, but it also isn't really needed, as Russ pointed out: On Mon, Mar 17, 2008 at 10:26:44AM -0700, Russ Allbery wrote: > There's no reason why we have to stick to one suffix. +s1+nmu1 for an NMU > after a security upload is ugly but functional, and the next maintainer > release would reset all the suffixes anyway. Likewise with appending > another +bN for a binary NMU. As near as I can tell, since you would > never base an NMU or security update on a binary NMU, the worst case is > +s1+nmu1+b1, which isn't really that horrible. You can base security uploads on NMUs, so I think you could get +s1+nmu1+s1+nmu1, etc. Or should it go from +s1 to +s1+nmu1 to +s2 to +s2+nmu1? I prefer the longer versions in this case. When a package gets too many security and other non-maintainer uploads, it should probably be orphaned or co-maintianed anyway (since there's appearantly a lot to do, and the maintainer isn't doing it). > > Turning "debian" into "deb" and "testing" into "+" would make it better > > "1.7.5+nmu3+deb3.1+.1" is comparable in length to the current > > "1.7.5+nmu3+lenny1" > > If you go this route, please make it +deb31, not +deb3.1. The extra dot > is historically special and indicates a binNMU. Hmm, the second dot probably has the same meaning then. So we should go for +deb31[+]_1 or something? To make it clear again: +deb is a fixed part which means this is a security upload 31 is the current (at time of upload) stable release + means this is an upload to testing, skipping it means to stable _ is a fixed part to separate the 31 and the 1 1 is a counter to allow more security uploads following this one. And once again the problem that is to be solved by this: When testing and stable are at the same version, and both get a security upload, the version in testing must not be lower than that in stable. 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
