* Michael Stapelberg: > Hi Florian, > > Florian Weimer <f...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bod65v7x....@mid.deneb.enyo.de