Keeping binary compatibility
l.lunak at suse.cz
Tue Oct 5 13:55:19 BST 2010
On Friday 01 of October 2010, Aaron J. Seigo wrote:
> On Friday, October 1, 2010, Lubos Lunak wrote:
> > with e.g. kdeedu libs? I'm asking because, consider e.g. these errors
> > from an attempt to uninstall kdebase/workspace package here:
> > libkscreensaver.so.5()(64bit) is needed by (installed)
> > kdeartwork4-screensaver-4.4.4-2.1.1.x86_64
> i think the expectation there was that kdeartwork would be installed in
> lock- step with kdebase. probably a hold over from the kde3 expectation of
> in any case, nothing in this library has changed in forever, but it also
> isn't ready to become binary compatible, mostly due to lack of dptr usage
> in public classes. that would be easy enough to fix, bump the .so #, and
> then commit that library to having BC.
It wasn't the point to discuss each of these libraries, they were just an
example showing that libraries provided by us are used by 3rd parties, even
if they are not part of kde(pim)libs.
Additionally, as far as expectations go, it is us that fail them. The normal
expectations are that whenever a library breaks its backwards compatibility,
it does a soname bump. Moreover, this "kdefoo should be installed only with
matching kdebar" expectation doesn't even seem to be said anywhere, and if it
is, it certainly has failed to reach anybody. I've checked kdeplasma-addons
packages for Fedora, Mandriva, openSUSE and Ubuntu and all of them just
depend on library sonames.
> > libkworkspace.so.4()(64bit) is needed by (installed)
> > ktorrent-3.3.4-4.1.x86_64 libkworkspace.so.4()(64bit) is needed by
> > (installed) kor-0.3-2.2s.x86_64 libsolidcontrol.so.4()(64bit) is needed
> > by (installed)
> > ktorrent-3.3.4-4.1.x86_64
> ktorrent shouldn't be linking to any of these.
> > - WTH does e.g. libtaskmanager seem to have soname versioning following
> > SC version, like stable kdelibs libraries do, but it's not actually
> > stable?
> because the intention was to eventually make it BC. it obviously didn't
> happen, things continue to evolve in it. we could certainly make a deadline
> for keeping BC (e.g. 4.6) and freeze it there. or we could keep going as we
> are currently (breaking BC from time to time, but not in a stable branch),
> and put NAMELINK_SKIP in there. would that be enough?
I suggest we do not reinvent the wheel. There has already been a good
solution for the last, I don't know, decades.
The problem is not that we don't keep BC for some libraries. The problem is
that we mess up BC for some libraries. If we did like (at least some of)
others and followed the usual rules, there would be no problem with BC
breakages in libtaskmanager, ktorrent using it, or any other of these
problems. Libraries can be packaged in a way that handles BC changes if they
are done properly, so it's more work trying to hide that we are lame than
stopping being lame.
> > Therefore I propose the following:
> > - private libraries do not (obviously ...?) install their .h files and do
> > use NAMELINK_SKIP option in install (see e.g.
> > http://websvn.kde.org/trunk/KDE/kdebase/workspace/khotkeys/libkhotkeyspri
> >va te/CMakeLists.txt?r1=862343&r2=895764)
> > - ABI stability for each public
> > library is documented, I would suggest a README.<library> file in sources
> > and in the main doxygen page
> README files tend to bitrot IME. apidox is a good place. techbase is
> another good place. a "whitelist" page showing all libraries that have BC
> commitments (with the implication that if we ship them, but they aren't on
> that list, don't expect BC) would make sense to me. it's probably the
> easiest place to find these things for 3rd parties.
I don't see why a techbase page should rot less than a README file that's
included with the library, nor why it should be easier to find (especially if
the README gets shipped together with the package). But I don't care that
much as long as it's said somewhere reasonable.
l.lunak at suse.cz
More information about the kde-core-devel