On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
> Bas Wijnen <[EMAIL PROTECTED]> writes:
> 
> > 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 was assuming the latter.
> 
> > 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).
> 
> We have other ways of tracking that information than the version, though.

Yes, and I don't really care, I just think going from +s1+nmu1 to +s2
seems to be doing things that it doesn't (revert the NMU).

> > Hmm, the second dot probably has the same meaning then.
> 
> This only matters when appended to a Debian revision; for native packages,
> it doesn't matter.  So ignore me unless we're talking about using the same
> convention for both native and non-native packages.

I was assuming to use the same convention indeed.

> > 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
> 
> Or any other stable upload, yes?

Yes, sorry.  I forgot that those exist as well. :-)

> > 31 is the current (at time of upload) stable release
> > + means this is an upload to testing, skipping it means to stable
> 
> You wouldn't need the presence/absence thing of the + if you used a higher
> version number for the testing security update.  I'd be inclined to say
> that we just always add 1 to the minor version of the last stable version
> when making a testing security upload until the actual version number for
> the next release has been picked.

Sounds good to me as well.

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

Reply via email to