PSA: some SO versions suddenly turning 0 with ECM 5.110

[Weng Xuetian]

Hi,
thank you for fixing this.

Also as upstream dev of fcitx, I can confirm that the library in
fcitx5-configtool is not affected since it's only currently used
internally.
libime-jyutping should be fine since it's on the end of dependencies.
I don't think there's anything in the real world using it other than
itself.

I surprisingly found that I actually workaround this ECM in libime
manually.. https://github.com/fcitx/libime/blob/8173e37b65bb7f9c67048929cd5f7dbf1f3b2b66/src/libime/core/CMakeLists.txt#L67
 but not in libime-jyupting.
I'll just bump the so version in those two projects in the next
version so they can work consistently on the old version of ECM.

On Fri, Sep 22, 2023 at 2:55 PM Friedrich W. H. Kossebau
<kossebau at kde.org> 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
>
>