Keeping binary compatibility

[George Kiagiadakis]

On Sun, Oct 3, 2010 at 12:14 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Saturday, October 2, 2010, George Kiagiadakis wrote:
>> % aptitude search
>> '?not(?source-package(kdebase-workspace))~Dlibweather-ion4a' p
>> plasma-dataengines-yawp  - yaWP's data engines (Ions) for
>> different weather servicesd
>
> does yawp actually _link_ to the ions? or does it just load them as DataEngine
> plugins at runtime?

It links to libweather_ion.so.4. Such package dependencies in debian
packages are determined automatically by checking the headers of the
binaries.

>> % 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
>>
>> % 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
>
> aside from kmess and ktorrent, these are things that are released together.

kmess and ktorrent + kdevelop, plasma-widget-yawp,
plasma-widget-fastuserswitch, sentinella, kshutdown, konq-plugins
(which is not released with the SC afaik, or at least there is no
konq-plugins 4.5) and lots of other apps and plasmoids from
kde-apps.org that are not packaged in debian.

> that they share such libraries is property of the SC release paradigm. it's
> not a bad thing. what is bad is that software outside of the SC does
> similarly, in part because we install headers so people can build modules
> separately.

I am not sure I agree to the "SC release paradigm". It is fine if a
private library is shared across the same module, but sharing it
across different modules causes problems because it is not always
possible to upgrade all the modules at once and causes unecessary pain
for the users. Different modules are different packages for us, there
isn't much difference between that and an extragear package.

However, this might be acceptable if BIC changes are documented for
each release, so that we know when different module versions can be
mixed and when they cannot. This will at least reduce the pain when
users need to mix different versions that *can* be used together. Of
course, the best way to achieve this would be to bump (or not bump, if
there is no BC break) sonames, which is immediately visible to the
packagers. So, I think we are back to the original proposal :)

> perhaps we need a "internal to KDE SC" header install location?

Application authors could still use them for apps outside the SC. How
are we going to force them not to do that? And what if they really
need the functionality provided by this library? That sounds like an
evil plan to pull even more applications into the SC while they could
perfectly fit in extragear or somewhere else.