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@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
