Keeping binary compatibility

[George Kiagiadakis]

First of all, thanks Lubos for bringing this topic again.

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.

Btw, there are more libraries in kdebase-workspace that are used externally:

% aptitude search '?not(?source-package(kdebase-workspace))~Dlibprocessui4a'
i   kdevelop     - integrated development environment for KDE
p   sentinella   - System monitor that can react to user chosen conditions

% aptitude search '?not(?source-package(kdebase-workspace))~Dlibweather-ion4a'
p   plasma-dataengines-yawp  - yaWP's data engines (Ions) for
different weather services

% aptitude search
'?not(?source-package(kdebase-workspace))~Dlibplasmaclock4b'
i A plasma-widgets-addons    - additional widgets for Plasma

(plasma-widgets-addons is kdeplasma-addons)

% aptitude search '?not(?source-package(kdebase-workspace))~Dlibkworkspace4'
p   kshutdown                      - an advanced shut down utility for
KDE
i   ktorrent                       - BitTorrent client based on the
KDE platform
p   plasma-widget-fastuserswitch   - Fast user switch plasmoid for
switching between sessions in KDE
i A plasma-widget-lancelot         - lancelot widget for Plasma

...and in kdebase-apps:

% aptitude search '?not(?source-package(kdebase))~Dlibkonq5a'
i   ark                       - archive utility
i A kdesdk-dolphin-plugins    - dolphin vcs plugins
c   kmess                     - MSN messenger for KDE
c   konq-plugins              - plugins for Konqueror, the KDE
file/web/document browser

...and in many more places...
...and insert lots of other stuff from kde-apps.org in the reverse
dependencies lists...

(Also note that some library package names have 'a' or 'b' appended,
which is because those libraries are known to have broken BC and we
had to bump their soversion downstream)


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

NAMELINK_SKIP and no headers installed. Yes, that would be enough imho.


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

Regards,
George