[Bug 245594] Re: Please add binNMU capabilities to Soyuz

[Scott Kitterman]

On Tue, 5 Aug 2008 13:54:37 +0200 Stefan Potyra 
<stefan.potyra at informatik.uni-erlangen.de> wrote:
>Hi,
>
>On Tuesday 05 August 2008 13:26:33 Scott Kitterman wrote:
>> On Tue, 5 Aug 2008 13:02:39 +0200 Stefan Potyra
>>
>> <stefan.potyra at informatik.uni-erlangen.de> wrote:
>> >Hi,
>> >
>> >On Tuesday 05 August 2008 12:28:55 Reinhard Tartler wrote:
>> >[..]
>> >
>> >> Could you please give a rationale why we don't want binNMUs in ubuntu,
>> >> but require sourceful uploads? I was under the impression that we 
don't
>> >> want this because there was no infrastructure for this. Now the 
request
>> >> for adding this is rejected on the grounds that policy forbids this. I
>> >> have the feeling we are turning in circles here, so could someone 
please
>> >> followup on the bug report?
>> >
>[..]
>>
>> Sometimes it's just needed to do one arch, not all of them.  
>
>hm... interesting, haven't thought about that case. Can you give an 
example? 
>The only thing I can think of right now is if you do rebuild for a 
transition 
>but don't adjust the build-dependency to require at least the transitioned 
>version. This however is bad for derivatives and gave me a hard time 
figuring 
>the correct order for earlier haskell transitions (which is now thankfully 
>fixed in debian :)).

The main case I've seen is where buildd backlog is sigificantly different 
on different archs and so the toolchain may have changed sufficently that a 
later build is against the correct toolset while the earlier is not.  The 
ability to rebuild per arch would avoid additional builds on slow archs.

Dependency adjustments are not always the right answer.  There are packages 
(for example) that will build and work fine with libclamav3 or 4, but we 
definitely want them built against libclamav4 in Intrepid.

>[..]
>> If your concerned about abuse,
>> maybe it could be restricted to core-dev or the release teams.
>
>Actually my concern is not about abuse, but rather about quality. (and I 
>didn't even mention testing the transitioned package in my previous mail).

OK.  Never mind about that then.

Scott K