KDE ABI stability?

Christian Loose christian.loose at hamburg.de
Mon Dec 5 18:45:40 GMT 2005

On Sunday 04 December 2005 18:47, Kevin Krammer wrote:
> On Sunday 04 December 2005 18:36, Thiago Macieira wrote:
> > Kevin Krammer wrote:
> > >> This means a program that compiled and ran with KDE 3.0.0 must still
> > >> compile and run with 3.5.0 (including running without re-compiling).
> > >
> > >Unfortunately this seems only be true for kdelibs. I remember a thread
> > > on debian-qt-kde (Debian KDE packagers list) about one of the other
> > > modules breaking BC in a library shared with another module.
> >
> > All *public* libraries are supposed to maintain BC. Non-public ones and
> > non-library code doesn't have to maintain.
> Sounds reasonable.
> > I am not sure whether libcvsservice was supposed to be public or not, but
> > it does have public headers. This looks like a bug from the cervisia
> > developers.
> Unfortunately nobody seemed to know about it. Both me and Ian Geiser
> (thread starter IIRC) insisted on the very thread that KDE was supposed to
> be binary stable within a major release but we were told that this wasn't
> the case.
> Even more unfortunately this had a bad impact on KDE's credability, i.e.
> "our" Debian packagers stay on the safe side and force removal of
> applications linking to an older KDE version than the one being installed.
> E.g. removing all 3.4 apps when 3.5 is installed as part of an upgrade,
> which results in all KDE .org applications to be updated as well (not so
> bad) but all third party packaged applications removed (not very nice)

Since I was the cause for the libcvsservice mess, my POV might be interesting 

1. What is libcvsservice?

libcvsservice is a small library that just contains DCOPStub classes for the 
cvs DCOP service (kdesdk/cervisia/cvsservice). I created it to make it easier 
for 3rd party developers (Quanta, KDevelop, etc) to use the service.

Looking back, this was a bad idea and I will remove it for KDE4.

2. What happened? What was the BIC change?

For a new feature, I needed to add parameters to an existing method in the 
DCOP interface. In order to ensure compatibility for existing users of the 
service (how ironic), I added copies of those methods with the new 

What I didn't know (and didn't check) was that the dcopidl2cpp tool declares 
all methods of the DCOP interface as virtual in the generated DCOPStub (see 
IMHO needlessly (and the author seems not to sure about it either) but this 
was the BIC change.

> Assuming that the bug was indeed a BIC change in libcvsservice, it could
> indicate that non-core developers are not aware of the binary compatability
> requirement or uncertain when a library has to be considered public.

I'm little confused why I was never contacted by the debian packagers.  I only 
know about this problem because  Andras Mantia wrote me a mail about it. We 
back then solved it for Quanta by not using the library at all.

I do know about KDEs BC requirements and that libcvsservice is a public 
library, but I didn't check the generated code of dcopidl2cpp. That was my 
big mistake.

Bye, Christian

More information about the kde-core-devel mailing list