Do we need to bump the shared library version for 2.4.0?

[Andreas Metzler]

On 2008-05-26 Simon Josefsson <simon at josefsson.org> wrote:
> In 2.3.x we have moved several symbols from libgnutls-extra to libgnutls
> (see complete explanation in the 2.4.0 release notes draft below), but
> do we need to bump the shared library version?  No symbols have been
> removed from any library libgnutls*, except for the symbols that have
> been moved.  libgnutls-extra links to libgnutls.

> I see several solutions here:

> 1) Increment the shared library version of libgnutls*.

>    This will cause an unnecessary shared library version break for
>    libgnutls, which have only had new functions added to it.  Given the
>    problem described in 2) I'm not sure how it could be avoided though.

> 2) Separate the shared library versions for libgnutls and
>    libgnutls-extra, and increment only the libgnutls-extra version.

>    This may be the The Right Thing to do, but it causes a new problem:
>    an application linking to libgnutls-extra.so.26 (2.2.x) may pull in
>    libgnutls.so from 2.4.x, which won't work together.  Both
>    libgnutls.so and libgnutls-extra.so would then provide the same
>    symbols.  If the application uses the one from libgnutls.so all is
>    fine, but it will break of the ones from libgnutls-extra.so is used.

> 3) Don't increment the shared library version at all.

>    The justification would be that we haven't removed any symbols, all
>    symbols in libgnutls-extra are still available via libgnutls and work
>    the same way.  The only thing that would break here is if someone is
>    dlopen'ing libgnutls-extra.so and calls the openpgp related
>    functions.  Strictly speaking I'm not sure this is a valid approach,
>    since we HAVE removed symbols from libgnutls-extra.
[...]
> I'm leaning towards 1) because of the problem in 2) and 3), however I do
> realize this will generate a lot of work for our packagers.

Hello,

nicely summed up.

Is (or has it ever been in > 2.2.0) gnutls-extra useable on its own?
I.e. is there a cause to be made for anything only linking against
gnutls-extra directly but not against libgnutls main? If correct usage
of gnutls-extra requires linking/dlopening libgnutls I think there is
strong case for 3.

Packagers generally would slightly also prefer 2 over 1. The problem
you noted is easily avoided for packages, since co-installion of
the different libraries can be prevented by using package
dependencies/conflicts. For Debian packages specifically, 2 would create
a problem since I currenly do not track packages using libgnutls-extra
separately. - Therefore anything linking against it would be broken
until rebuilt. - I am only mentioning this for completeness sake, I
do not think Debian-specic issues should be an important point.

cu andreas
PS: I you bump so names, please also bump symbol versioning.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'