Re: Mysterious NMU (Bug #423455)
Roberto C. Sánchez <roberto@connexer.com> writes:
> On Tue, May 15, 2007 at 03:49:07PM +0200, Goswin von Brederlow wrote:
>> Roberto C. Sánchez <roberto@connexer.com> writes:
>>
>> > On Mon, May 14, 2007 at 09:24:35AM +0200, Raphael Hertzog wrote:
>> > Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
>> > 1.0.1-2) be more correct? That way the package is still binNMU safe and
>> > also safe from breaking if incompatibilities are introduced in the next
>> > source upload?
>> >
>> > Regards,
>> >
>> > -Roberto
>>
>> (>= version) and (<< next-version).
>>
>> The problem is knowing next-version. 1.0.1-2 is not the next
>> version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
>> (security update for lenny) is less than 1.0.1-2. There could also be
>> an 1.0.1-2~rc1, again less than 1.0.1-2.
>>
> Yes, but in reality what is the likelihood that either a security update
> or NMU would introduce an incompatible change? I would say that such a
> possibility is extremely low.
>
>> And now for something really ugly:
>>
>> % dpkg --compare-versions "1.0.1-1lenny1" "<<" "1.0.1-1+b1" && echo yes
>> yes
>>
>> So a security upload of the package has a smaller version than a
>> binNMU upload. At that point you are pretty much screwed.
>>
> Perhaps the policy should change so that security uploads are done with
> x.y.z-(w++)~lenny1? That is, the Debian version number gets
> incremented.
>
> Regards,
>
> -Roberto
I suggested 1.2-3+s.lenny.1 in the past. More specifically:
1.2-3+a0... for local/vendor recompiles without source changes.
1.2-3+bX for binary NMU
1.2-3+c0... for local/vendor changes with source changes
1.2-3+s... for security updates
So for example an ubuntu patched package of foo would be
1.2-3+c0.ubunt.
MfG
Goswin
Reply to: