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

[Bernhard Reiter]

https://chaos.social/@dvzrv/114125610003036424
notes that

> It appears also Gentoo Linux is affected (see 
> https://social.treehouse.systems/@thesamesam/114120915949943686). 

> I believe that this situation could have been resolved by changing the 
> soname once more when changing the symbols in 3.0.1. 

> As is, I think another soname change should be made and the version 3.0.0, 
> 3.0.1 and 3.0.2 should be marked as "do not use". 

Okay, would bumping the soname again with 3.0.3 or be helpful?
(At least this is what I understood is suggested. But I lack experience
with all the packaging to estimate the consequences. All I want is
Arch, Gentoo and others have a good paths forward.)

Am Freitag 07 März 2025 18:54:24 schrieb Simon Josefsson via Gnupg-devel:
> Bernhard Reiter via Gnupg-devel <gnupg-devel at gnupg.org> writes:
> > 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.

Thanks Simon, I've forwarded to your suggestion (in a reply to the 
Fediverse post linked at the top).

Best Regards,
Bernhard

-- 
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250310/d57af8be/attachment.sig>