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

[Guillem Jover <guillem@debian.org>]

On Mon, 2014-07-14 at 14:09:55 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > 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.

Not necessarily.

> 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),

Just to clarify, you get a warning when using an object build-time
linked against a versioned library and then run-time linked with an
unversioned instance. But this is not a new scenario, it's similar
to using new symbol semantics or new symbols from a library, one just
needs to bump the dpkg shlibs or symbol minimum versions to get proper
dependencies.

> 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.

If the switch allows for the old namespaced symbol versions to be kept,
then both versioned symbols can be provided via aliases. But that might
defeat the reason for the switch, so it might not be always feasible.

Regards,
Guillem