Keeping binary compatibility

[Lubos Lunak]

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
> things.
>
> 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.

 Says who?

> > - 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.

-- 
 Lubos Lunak
 l.lunak at suse.cz