Handling BIC-without-SONAME-bump in KDE SC libraries

[Modestas Vainius]

Hello,

I personally can't comment on how much upstream improved after the last 
discussion (iirc, on kde-core-devel). However, it would be naive to think that 
we will never face BIC-without-SONAME-bump problems in the future. Solving 
them all upstream would be great but it's simply too optimistic scenario due 
to many factors.

Generally I can think of two ways of dealing with this. The first is our 
policy at the moment.

1. [ Package level ]. Rename the library package and add Breaks/Replaces 
against the previous versions, keep library SONAME (and filenames) unchanged.

Pros:

a) binary compatible with upstream and other distributions (at least in 
theory);

b) ensures users have no old BIC libs (and apps linked to them) around. If an 
app ends up directly or indirectly linked to the old and new library with the 
same symbols, bad things may happen (e.g. recent libpng case and see below);

c) does not require patching of upstream source.

Cons:

a) apt unfriendly because two library packages cannot be co-installed. Library 
packages are typically deep in the dependency chain so apt may require to 
force removal/installation in some cases;

b) makes partial upgrade to new KDE releases very painful. I.e. it renders 
some 3rd party applications uninstallable due to conflicting library packages;

2. [ Library level ]. Change library SONAME (e.g. add debN suffix, specifics 
to be discussed) and rename the package. No Breaks/Replaces needed as there 
are no conflicting files.

Pros:

a) apt friendly as it's a recommended way to deal with SONAME changes;

b) new KDE releases should no longer break 3rd party applications (at least at 
the package management level);

Cons:

a) custom SONAMEs and library filenames will be binary incompatible with the 
rest of the world;

b) if conflicting libraries are loaded in the same app memory space (unlikely 
though), it might lead to crashes at runtime;

c) crashes might occur due incompatibilities in the runtime client/server 
protocols (if there are ones);

d) requires patching of upstream source (i.e. altering SOVERSION in the 
CMakeLists.txt);

So what I am proposing is the switch to 2). I do believe that user experience 
is more important than SONAME compatibility with the rest of the world (which 
is theoretical anyway, at least in the KDE land). IMHO, other cons are not a 
big deal either as KDE is not libpng and runtime conflicts are more unlikely 
than likely.

So what do you think and which way do you prefer? Maybe we could think of 
something better?

-- 
Modestas Vainius <modax at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20110315/da2c08de/attachment.pgp>