Keeping binary compatibility

[Andreas Pakulat]

On 02.10.10 16:52:34, George Kiagiadakis wrote:
> On Fri, Oct 1, 2010 at 11:12 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Friday, October 1, 2010, Lubos Lunak wrote:
> >> 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.
> >
> >> libsolidcontrol.so.4()(64bit) is needed by (installed)
> >>     kbluetooth-0.4.2-3.1.x86_64
> >> libsolidcontrol.so.4()(64bit) is needed by (installed)
> >>     NetworkManager-kde4-libs-0.9.svn1057339-4.1.x86_64
> >
> > afaik libsolidcontrol is being phased out. networkmanager is also likely to be
> > moving into kdebase/workspace/ at some point anyways, which will make this one
> > "go away". kbluetooth is perhaps another good candidate for similar movement.
> >
> >> libtaskmanager.so.4()(64bit) is needed by (installed)
> >>     ktorrent-3.3.4-4.1.x86_64
> >
> > oi vey. another library they should not be linking to.
> 
> If such libraries are not meant to be used by the outside world, then
> *please* let's stop installing headers for them. Let's make that a
> policy somewhere: Headers must not be installed unless the library has
> BC guarantees or the author commits to bumping soversion properly.

Thing is that nobody tells developers starting to work on some libraries
that there's something like a soversion in libs. All our pages do is
explain that kdelibs is guarantee'ing BC and what that means. So one
thing that needs to be added to techbase is a section explaining what to
do for libs in modules like kdegames, kdeedu etc. where they do want
libs+headers installed for games in playround and extragear. When I
hacked a bit on kdegames about 2 years ago (IIRC) nobody in the team
really had an idea about soversion/bc guarantee's of the libs.

> >> - ABI of each stable library (obviously) does not change
> >> - whenever ABI of an unstable library changes, its soname is increased
> >> (which means that each library will need in its CMakeLists.txt something
> >> like this
> >> http://websvn.kde.org/trunk/KDE/kdelibs/plasma/CMakeLists.txt?r1=879765&r2
> >> =879766& , handled manually, instead of generic macros)
> >> - the release team howto gets a new entry 'each new version is ABI tested
> >> before release'
> 
> +1 to all of the above.
> 
> An additional idea is to completely remove the
> GENERIC_LIB_{,SO}VERSION cmake variables from the kde scripts so that
> new library authors are required to understand the concept and use
> their own version, instead of just using these magic cmake variables
> that they have copied from some other library and have no idea what
> they mean.

Its far too late for that, the variables have been available since
multiple KDE releases. Removing them means breaking SC and thats not
allowed for KDE's buildsystem files for the lifetime of KDE4.

Andreas

-- 
Slow day.  Practice crawling.