Re: raising an issue about static linking policy
On Thu, Aug 28, 2014 at 11:38:49PM +0200, Salvo Tomaselli 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 really don't understand some of the point that Linus is trying
to make.
Some random comments:
- We have a policy that says we want shared libaries, except in a
few cases, and it might apply to libgit.
- I except all library packages to ship a static library even when
there is a shared version, but policy doesn't really require this.
- Their is an open bug against policy about applications linking
staticly to libraries. We don't discourage linking staticly
(yet).
- I really don't understand Linus' comment about the binary
compatibility. The problem is that libgit does not provide
binary compatibility, while most libraries do try to provide
the ABI compatible and that we have various ways of dealing
with the problem if the ABI gets changed. *We* are not throwing
sanity away, we are trying to bring sanity.
- I don't see how dynamic linking negates versioning issues. In
fact I think because we have dynamic linking people actually
care about the ABI and so we have less problems.
- I can't see how libxml wouldn't be a core package. Maybe he
should check how many copies of that he has open.
- Static linking is a security nightmare, as are embedded copies
of libraries. It creates additional work and it's not clear
which applications are all affected.
Kurt
Reply to: