Consider setting SONAME to major.minor

[Undef-a]

This allows Calamares extensions built against a patch version to be run against another patch version. It fixes the mobile (and similar) modules silently breaking when Calamares is independently updated.

Specifically, this should help mitigate issues like https://gitlab.com/mobian1/issues/-/issues/438, where an update from Debian's Calamares breaks all usage of Calamares extensions. Right now we see this issue crop up most months as Calamares and Calamares Extensions are maintained by separate people.

The commit in this PR implements this, but I'm opening the PR more as a discussion on whether we could make this change in libcalamares than as a preferred way of doing it.

Thanks for considering.

[spaetz]

If you don't want two places in which you need to bump version numbers, you could even construct the SO Version number from CALAMARES_VERSION_MAJOR CALAMARES_VERSION_MINOR which we have available, so it would work automagically?!

[adriaandegroot]

If you move this below the project() command you can use the major, minor parts and don't have to repeat it here. You could even skip setting this entirely and just use major.minor down below, but you could also just choose to set this to "4" and call that the soversion.

[adriaandegroot]

There has never been a promise of ABI stability in Calamares; the functions in libcalamares have changed a lot over the course of the 3.2 series, always with the Calamares version as SO version: there's no guarantee any two of the 3.2.x versions were in any way compatible with each other. Once 3.3 is actually released, then we might consider ABI stability (in which case 3.3, or 4, might make sense as an SO version).

If we use the ci/abicheck.sh script we could keep track of actual compatibility -- otherwise the major.minor SO version is just a lie. You can make use of that script: for instance, run it and add the output to ci/ as, I dunno, abi-so-3.3. Then, in the release script, run the abi check and compare against the stored text. Then we can make sure that the SO version is useful and correct.

[kkofler]

A pull request is not a good place to discuss ABI stability policies. The ABI policies need to be discussed and agreed on before it makes sense to submit an implementation.

[adriaandegroot]

(The contribution guide suggests exactly what is happening here: open a PR early, in order to discuss whether this is a worthwhile avenue to pursue; unless there are qualitatively-different discussion possibilities elsewhere, this is the best place)

So to reiterate:

• having a 3.3 SO (or whatever) might be useful, but only if you also help out in supporting ABI stability,
• for the 3.2 series, we know that having a 3.2 SO version would not have worked: instead of "missing 3.2.x" library, modules would link to 3.2 and then mysteriously crash because the ABI changed out from under them.

A PR that addresses only the "make a symlink" part is insufficient, but can be expanded with documentation, script integration, etc. (also, remember there's no 3.3.0 yet, so the libraries may change at any time until then).

[adriaandegroot]

@Undef-a closing this again. It needs more work than just setting an SO version, as explained above (effectively, if there's an SO version set the way you propose, then the only realistic thing to do with Calamares as it is developed now, is bump the version every release since nothing else checks for stability -- and let's not forget that along the Arch side, rolling Python or Boost updates break Calamares all the time as well; that's not relevant for your Mobian, but an additional data point)

[Undef-a]

Sorry for the delay, this just made it back to the top of my list today.

To make sure I'm on the right track, this MR would be considered only with a compatibility check in CI for libcalamares and only for 3.3/4.0 when released? That still sounds like a pretty big win to me and I'm happy to work on it.

As an alternative, would it be worth considering just pulling the regularly used calamares-extensions modules into this repository? At least from my perspective, that would remove any need for ABI compatibility as they would all be re-built together.

[adriaandegroot]

Come to think of it:

• 3.2 should be stable now; it's in long(-ish) term support, so there should be some pressure to keep the ABI stable (if only because no changes are expected)
• 3.3 should try to be stable in the longer term, or at least be more explicit about ABI changes for the modules (though, like I've said, the major drivers for ABI issues are Boost, Python, and to a far lesser degree, kpmcore)
• ci/abicheck.sh can already do most of the checks, using libabigail. I think it already keeps around the ABI information after generation, so a straightforward adjustment of the BASE_VERSION (in whichever branch) would work. I think adding the ABI information to the ci/ directory, if it isn't too large, would be ok (just to avoid having to rebuild it every single time)
• CI could check and report on ABI issues (for instance, in the calamares branch, on push)
• The release script should check compatibility (in the 3.3 branch, at least). Doesn't have to block a release, but it would be a thing to report in the release notes ("ABI has changed; all C++-based modules must be rebuilt")

As for the calamares-extensions repository, the whole point is that there are non-core modules there (and we could easily argue that several modules in the calamares repository belong over there as well). If there's modules there that are core (and that means "applicable to multiple families of distro's", not "important for your one distro") then that's a separate conversation to be had (it may make sense in the 3.3 pre-release state to go over the modules again).

[adriaandegroot]

Abigail produces this kind of ABI information (for the calamares branch, where we know we're changing the ABI until it looks right for a 3.3.0 release):

  [C] 'method QPair<unsigned long long, float> CalamaresUtils::System::getTotalMemoryB()' at CalamaresUtilsSystem.cpp:234:1 has some sub-type changes:
    return type changed:
      type name changed from 'QPair<unsigned long long, float>' to 'QPair<unsigned long long, double>'
      type size hasn't changed

The abigail information is ~18MB so that's a no-go for adding it directly to the repository. That makes it possibly something to check regularly in CI by re-generating the information, or if CI supports caching artifacts, doing it there.