Loïc Minier <[EMAIL PROTECTED]> writes:
> 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,
Not at all. '+b' still sorts higher than 'sarge.'. The only thing the
new scheme fixes is that now binNMUs have a 'Source: foo (1.2-3)'
entry linking it to the actual source version.
During the discussion of using +b for binNMUs it was also suggested to
use +s for security uploads. And sicne b << s that would solve the
problem.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
