Do we need to bump the shared library version for 2.4.0?
ametzler at downhill.at.eu.org
Mon May 26 20:23:24 CEST 2008
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.
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.
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'
More information about the Gnutls-devel