On Wed, Nov 23, 2005, Goswin von Brederlow wrote: > What is your point? > > In my example the binNMU done _BEFORE_ the security release sorts > _AFTER_ the security release. So updates will not get the fix.
I think we saw different use cases, I interpreted your example as: 1/ upload happens 2/ security upload happens 3/ bin NMU of 1/ happens and I saw no point of bin NMUing 1/ instead of 2/... but you probably meant: 1/ upload happens 2/ bin NMU of 1/ happens 3/ security upload of 1/ happens and has a lower version number than 2/ which is of course a problem because people with 2/ won't get the security update. This I did not understand in your first message, and it's now clear to me that we were in need of a new scheme for bin NMUs so that they get a lower priority than other source branches. I suppose this was particularly a risk for people maintaining packages as bin NMUs of Debian packages. > PS: 1.2-3.0.1 binNMU gets rejected by DAK now, only 1.2-3+b1 is > accepted. As I understand it, all problems that appeared in this discussion are solved with the new scheme. Bye, -- Loïc Minier <[EMAIL PROTECTED]> "What do we want? BRAINS! When do we want it? BRAINS!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
