Re: raising an issue about static linking policy

[Reinhard Tartler <siretart@gmail.com>]

On Thu, Aug 28, 2014 at 5:38 PM, Salvo Tomaselli <tiposchi@tiscali.it> wrote:
> Hello,
>
> I've recently packaged subsurface 4.2 for experimental, because it depends on
> libgit2 which is in experimental…
>
> I think you might want to read these posts:
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014520.html
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014524.html
>
>
>> And this is just one reason why distributions should not do the whole
>> insane "dynamic linking only" strategy.
>
>> Dynamic linking should be for core distro packages only. Not for random
>> other stuff. That's *particularly* true for random oddball libraries (is
>> libgit2 but also libdivecomputer or even things like libxml).
>
>> The advantages of dynamic linking are totally negated by (a) versioning
>> issues and (b) lack of wide sharing.
>
>> Just look at what all external entities end up *having* to do (ie think
>> valve etc). Debian should rethink its policies wrt dynamic libraries,
>> because the current one is wrong for users, and wrong for developers.  But
>> also wrong for purely technical reasons.
>
>> Could someone involved with Debian please try to take this issue up? I'm
>> fed up with how the kernel makes binary compatibility such a priority, only
>> to have distributions throw all that sanity and effort away.
>
>>     Linus
>
>
> I have no opinion on the topic at the moment, except that it is no ideal to
> have the new version stuck in experimental, but I thought it is worth to relay
> and have some discussion about this.

Since libgit seems to be rather volatile (API wise), what's the
problem with following upstream's advice and make the package povide a
static library only? Two reasons come to my mind:

 1.) A security fix need to requires compilation in many other packages
 2.) An API break will silently break other packages, and will
surprise silently on the next package upload, which may or may not be
urgent

Both can be handled by the maintainer when dealt with care and he is
willing to actively (!) ensure that both points are not a problem (for
instance, by tracking the exported symbols on each upstream release
and/or recompile all application packages that link against libgit -
again on each and every upload of a new upstream release). The number
of packages that link against the static library is an important
metric to take into consideration here: If we are only talking about
two or three applications that are maintained by the same maintainer
or even team, then it may be OK, however if we are talking about
dozens applications and maintainers involved, then I as maintainer
would refuse to engage this mess.

-- 
regards,
    Reinhard