Use versioned SONAMEs in libaktualizr

[charles2910]

Hi,

I'm packaging aktualizr (actually our fork toradex/aktualizr) for Toradex and noticed libaktualizr does not use versioned SONAMEs.

Using SONAME for managing ABI compatibility is very important because it allows other users to compile a binary against one version of the library and continue using it with newer versions of aktualizr while there isn't a SONAME bump which indicates binary incompatibility.

CMake supports declaring SONAME via https://cmake.org/cmake/help/v3.30/prop_tgt/SOVERSION.html#soversion and it should be bumped every time there are incompatible changes in public exposed structs or functions.

Some good documentation on the matter is available at https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

[cajun-rat]

Thank you for participating it is good to have you on board!

Fixing the SONAME is unfortunately the easy bit of the work to ensure ABI compatibility. In order to make it work we'd need to have set of APIs into Aktualizr that have stable ABIs. This is notoriously difficult in C++, and most projects seem to use a C API, which is easier to keep stable. We kinda have one in aktualizr-c but it isn't very complete and I'm not aware of any active users.

The problem is that designing APIs that are a) stable and b) can continue to be provided as Aktualizr is expanded is hard. At the very least you need tooling to detect ABI changes (RedHat have some) and a suite of regression tests, but the main problem giving low enough level access to allow library users to usefully expand Aktualizr without making the codebase impossible to improve.

None of this is impossible, but it comes at significant engineering cost that cannot be spent elsewhere. The alternative, as practised by the Linux Kernel and Google is 'Live At Head'. This is what we've done until now in Aktualizr. The idea is that if you want to add a new use case, then don't depend on us as a library, instead add it directly to the codebase and enable it via runtime configuration. This way your tests for your feature are run on every commit, and everyone can make refactorings across what would otherwise be a hard ABI boundary. That lower friction for improvements allows for a higher quality codebase overall.

That said, I'm not against someone looking after the C API or improving it. What it the high level goal that you're trying to achieve?

[charles2910]

Sorry for the delay, it has been a pretty busy couple weeks at work.

So, the first thing I have to say is I always wear two hats, one is Toradex developer and the other is Debian contributor.

This specific request is more on the Debian contributor side of things (always looking for software that could be included in Debian), because Debian policy strongly recommends versioned sonames for shared library in /usr/lib path. There are some projects that choose to version the soname with major.minor.patch, so it's always bumping the soname at every release. Other software choose to move the shared library to /usr/lib/<project name> so it's out of the public library space and programs have to proactively link to it.

In the end, I don't have the expertise to do it, so it's okay if you guys think it's better to just close this issue.

[cajun-rat]

If giving every 'released' version a different soname version is a useful thing for Debian packaging, then I'm cool with adding that. It sounds like a reasonable way to avoid worrying about ABI compatibility. The meta-updater builds are done from the latest master, but there is nothing stopping us tagging version number as part of the work to bump the Debian package, which could feed into the soname version.

[charles2910]

That would be very helpful for anyone using aktualizr. Though there are more things that would preventing it from being added to Debian. Mainly the embedded/vendored libraries are a no-go for Debian - but I think that would be all actually.