libassuan 3.0.0 bumped the soname without bumping the symbol versioning

Andreas Metzler ametzler at bebt.de
Mon Jun 24 18:20:18 CEST 2024


On 2024-06-24 Werner Koch <wk at gnupg.org> wrote:
> Hi!
> On Sat, 22 Jun 2024 18:18, Andreas Metzler said:

> > Could you do a quick 3.0.1 release to fix this before it has found its way
> > into the major distributions?

> Just did this:

> #+macro: libassuan_ver  3.0.1
> #+macro: libassuan_date 2024-06-24
> #+macro: libassuan_size 578k
> #+macro: libassuan_sha1 776aac6fe4a64f29406bb498e0b2b73f2622c799
> #+macro: libassuan_sha2 c8f0f42e6103dea4b1a6a483cb556654e97302c7465308f58363778f95f194b1

> 776aac6fe4a64f29406bb498e0b2b73f2622c799  libassuan-3.0.1.tar.bz2
[...]

Thank you very much!

> I don't think that using symbol versions for a transitioning process is
> a good idea.  There actual use case is to allow several symbols in the
> same library to avoid an ABI break (for example if a parameter is added
> to a fucntion).

> Having several versions of a library linked into one process is simply
> wrong unless that library has been written with such a use case in mind.
> All kind of subtle error may show up and it is a support hassle.  We
> seen that in the past at least with GnuTLS linked directly to dirmngr
> and also with another version due to Openldap.
[...]

Noted, we do not plan to have this for an extended period of time.

cu Andreas
-- 
`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 Gnupg-devel mailing list