ArchLinux libassuan upgrade problem (related to: libassuan 3.0.0 bumped the soname without bumping the symbol versioning)

[Simon Josefsson]

Bernhard Reiter via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> Hi,
>
> got a problem report via the fediverse. 
>
> == Background
>
> libassuan-3.0.0.tar.bz2	came on 2024-06-18
> and six days later there is 3.0.1 as quick-release upgrading the soname
> to what it should have been (see citation below).
>
> == Problem description
>
> Arch Linux packaged the 3.0.0 release and has problems upgrading from it now.
> Here is the problem description:
>
> "
> with the release of 3.0.0 the soname changed from libassuan.so.0 to 
> libassuan.so.9.
> Only with 3.0.1 the symbols have been changed from LIBASSUAN_1.0 to 
> LIBASSUAN_2.0 (which is the ABI breaking change that the soname change is 
> supposed to indicate).
>
> Since #pacman requires the library transitively via #gpgme, there now is no 
> clean way to upgrade this without patching all consumers in some intermediate 
> step. (The staging build environment would otherwise have a broken pacman and 
> thus not be functional).
>
> We are stuck on 3.0.0 because our packaging environment now requires 
> libassuan.so.9 with symbols LIBASSUAN_1.0.
> "
>
> Does anybody have some ideas how to solve this for Arch Linux in an elegant 
> and efficiant way?

How about a ArchLinux-specific patch to the libassuan 3.0.1 package to
re-add so that the LIBASSUAN_1.0 symbol names are ALSO available?

Then binaries linked against 3.0.0 will at least still behave the same
with 3.0.1 as they did with 3.0.0, which may not be fully correct
because some symbols may have changed their meaning compared to 2.x
which presumably those packages were written to assume.

All binaries built against 3.0.0 would then have to be rebuilt with
3.0.1 to start to use the LIBASSUAN_2.0 names.  Then future upgrades
should work.  You have to keep the LIBASSUAN_1.0 symbol alias for as
long as you want to support binaries built with the broken 3.0.0.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250307/2bb3f956/attachment.sig>