[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon

Harald Sitter bugzilla_noreply at kde.org
Fri Feb 19 10:21:02 GMT 2021


https://bugs.kde.org/show_bug.cgi?id=433090

--- Comment #9 from Harald Sitter <sitter at kde.org> ---
(In reply to Antonio Rojas from comment #8)
> (In reply to Harald Sitter from comment #7)
> > That may well be but then the soversion will still have to change.
> > 
> > The only options for any library are:
> > 
> > a) when ABI is broken the soversion is bumped
> > b) nobody checks if ABI is broken and the soversion is directly tied to the
> > release version e.g. the there is no libfoo.so.5 but only a
> > libfoo.so.5.20.12.2
> > c) the library has no version, is considered private, and doesn't advertise
> > itself for external use (install with NAMELINK_SKIP + no cmake config)
> > 
> > One may pick any of the three.
> 
> (b) would be a nightmare for packagers, we'd need to rebuild everything
> after every bug fix release (note that this affects every PIM library, not
> just akonadi)
> For (c) it is too late, there is stuff using pim libraries already.
> The right way is (a), but good luck trying to convince kdepim devs of that :)

Heh. Distros can always opt out of b) and patch it to a) ;).

Though I'm not sure I understand the concern. If pim devs don't pay attention
to the ABI then in what scenario would a distro not rebuild everything? Or I
guess to preempt the answer a bit, if distros can tell if ABI was broken, why
can't we, KDE, and bump the version when that happens. The bottom line here is
that proper so versioning is not the same as ABI stability. Just because pim
doesn't care about ABI stability doesn't mean we should release clearly
incorrectly versioned libraries. In particular when even our own software
outside the release-service is using it, so the "oh but this library is not for
third parties" excuse doesn't even fly here :|

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Kdepim-bugs mailing list