On 2024-06-24 Werner Koch <w...@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' _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
