PSA: some SO versions suddenly turning 0 with ECM 5.110

[Alessandro Astone]

Thanks!

How did you include fcitx5-configtool in the list of affected packages?
Checking the Fedora repositories it only depends on KWidgetsAddons and 
KItemViews, both of which are not affected by the change.

On 22/09/23 23:55, Friedrich W. H. Kossebau wrote:
> Hi,
>
> A recent fix in ECMSetupVersion, released two weeks ago with ECM 5.110, is
> turning out to uncover a few unintended usages, resulting now in sudden SO
> version changes on a plain package rebuild (so potentially breaking linking of
> libraries by other packages)
>
> Seems there are not too many affected, and possibly only non-"central" ones,
> with few external linkages or just application-internal.
>
>
> ACTION REQUESTED
>
> Still, might cause breakages perhaps for some. Reverting the change in ECM
> might be too late now, so let's instead for now just collect a list of known
> affected packages, so binary distributions can double-check dependencies and
> possibly fix things by rebuilding those as needed.
>
> Please amend this list (and check as your packages as needed):
> * fcitx5-configtool
> * libime-jyutping
> * kjournald
>
>
> BREAKAGE TO NOTICE
>
> A plain rebuild of a package with now ECM 5.110 will suddenly turn the SO
> version of libraries into "0", instead of "5" or similar (typically the
> project major version number).
>
>
> CAUSE
>
> While the docs state
>
>      <prefix>_SOVERSION - <soversion>, or <major> if SOVERSION was not given
>
> (https://api.kde.org/ecm/module/ECMSetupVersion.html?highlight=SOVERSION)
> by a bug instead when passing "0" as SO version
>   
>      ecm_setup_version(${some_version}
>          // [...]
>          SOVERSION 0
>      )
>
> this was treated as if the argument was not given.
>
> This behaviour was fixed for ECM 5.110 in
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/378
> so now also "0" is treated accordingly as normal SO version number
>
> Sadly it had not been assumed that actually "0" has beeng used in some places
> already, and those projects just might not have been aware of the mismatch (or
> maybe even had not read the docs and assumed the behaviour as "normal",
> despite "0" being actually common value).
>
> Luckily some projects like kasync or kimap2 also have "0" as major version
> number, so no effect seen with those.
>
> Other libraries are application internal, not linked externally, so might
> break only with non-globbed package manifests, but not other packages.
>
>
> Sorry for stirring up some things by what was intended just a fix,
>
> Cheers
> Friedrich
>
>