Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL

[Henrique de Moraes Holschuh <hmh@debian.org>]

On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> I plan to try and get them to use symbol versioning, at least on
> those platforms that support it.  This will probably be just like

Thank you.

> the patch currently in Debian.  I don't plan to add multiple
> versions of a symbol to try and keep the same soname since that
> probably won't work on all platforms.

We want _all_ visible libressl symbols versioned, but that's for protective
namespacing, and not for backwards binary compatibility.  That's why it
should be a libressl-specific symbol version, since full guaranteed
*internal* ABI compatibility with openssl is not really happening.

We've been through this hell with libpng, libsasl, and openssl itself...
I still think we should forbid any libraries with unversioned symbols in
Debian, unless they're guaranteed to never be linked by other libraries
(including nss modules and the like).  Solaris got this idea right nearly
two decades ago.

Use of symbol versioning for providing several versions of the same symbol
for backwards binary compatibility (like it is done by glibc) has its own
problems and limitations.  Those were rehearsed ad nauseam some years ago,
and that's _not_ what we're talking about here, anyway.

> We also plan to reduce the risk of breaking the ABI.  Now a lot of
> structs are public and we would like to make them private and
> provide functions for those things that people want to access.

Seems sensible.

> This will all probably take some time.

As long as you don't mean to wait to deploy symbol versioning.  It becomes
*really* painful after a while.  Changes to symbol versioning requires
everyone to recompile everything that uses the library.

It is bad enough when you go from unversioned to versioned symbols (the
binary will still run but you get a warning about it every time), but it is
hell when you switch[1] symbol versioning decoupled from a major soname
bump, because everything that is not recompiled with the new symbols will
fail to runtime link, requiring coordinated transitions/flag-days to avoid
this.

[1] as in change the namespace, and _not_ as in provide a new version of
symbols while also providing the older versions of the symbol around.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh