Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Hendrik Sattler wrote:
>> Am Montag, 29. Mai 2006 21:16 schrieb Thomas Viehmann:
>>> Hendrik Sattler wrote:
>>>> No, but you could manually set all stuff in Depends to the needed
>>>> versions. That would also work for the buildds, I guess.
>>> And break at the next opportunity (binNMU, recompile, update in a
>>> hurry...).
>
>>  he automated shared lib dependency calculation surely works but does not 
>> always give optiomal results, e.g. it will pin to a specific libc (building 
>> packages of non-free apps is sometimes better done with setting the depends 
>> manually).
>>From a Debian point of view, correct and minimal dependencies is a
> (very) global problem, with correctness being a hard condition and
> minimal not. In particular, local optimization towards minimal that
> raise the probability of incorrect over package life time, are not a way
> to go.
> Experience shows automatism is asked for because the problem rate is far
> lower. It doesn't any harm, either, does it?
> Don't take my word for it, but do trust Steve's expert opinion. Debian
> is large enough to predict "there will be N errors" in every "the
> maintainer will have to be careful here", so your arguments are void...
>
>> binNMU & recompilation: won't break if the app really works with this older 
>> version and the lib must be ABI-compatible anyway.
> ... and this one is plainly wrong. binNMUs for rebuild against
> dependency libs which have changed ABI are not only possible but
> routinely done. Transition NMUs would be hard to get correct as well.

s/changed/extended/

Any ABI change must be acompanied by a soname change.

>> Automatism is good but not the only way to do stuff.
> For Debian packages taking clever shortcuts that are almost certain to
> fire back is inacceptable. We all do the "create a Debian package using
> ar" thing once, but we all agree that this isn't the way to do it.
>
> Kind regards
>
> T.

MfG
        Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to