Re: [RFC] Go (golang) packaging
* Michael Stapelberg:
> Hi Florian,
>
> Florian Weimer <fw@deneb.enyo.de> writes:
>>> Could you provide an example please? I don’t understand how this is
>>> different with static linking than with dynamic linking yet.
>>
>> With dynamic linking, you pick up the behavior change along with
>> "apt-get upgrade", so I expect that we get much more testing of the
>> combination during development.
> I’m still not sure I understand you. Could you please provide an
> example? Participating in this discussion makes no sense for me until I
> understand your point.
Okay. Suppose you statically link into your application a copy of
OpenSSL and use it to make TLS connections, in a way that causes
OpenSSL to pick the highest supported TLS version. We upgrade OpenSSL
and add TLSv1.2 support to it (or we remove RC4 support). It turns
out that the application connects to a server which is broken and
refuses to handshake at version 1.2. This means that if we recompile
the application, linking against the current OpenSSL version and
incidentally enabling TLSv1.2 support, it ceases to work.
With dynamic linking, we'd see this immediately, as soon as OpenSSL
upgraded (say, because it has entered testing). With static linking,
we might never see it at all because a recompilation is necessary to
expose the non-working combination.
One might argue that the static case is actually better because it is
more predictable, but our post-release support model is heavily
dependent on minimal changes (because we cannot do full QA
post-release). Such minimal changes are impossible with static
linking, unless we aggressively recompile and relink reverse
dependencies as soon as possible, so that we have no lingering
outdated copies in a release.
I hope this clarifies things a bit.
Reply to: