RFC: adding a temporary, non-BC gauranteed, 'private' library .. where?

Andreas Pakulat apaku at gmx.de
Thu Apr 23 18:55:41 BST 2009

On 23.04.09 15:00:05, Sune Vuorela wrote:
> On 2009-04-23, Allen Winter <winter at kde.org> wrote:
> > On Wednesday 22 April 2009 4:21:51 pm Aaron J. Seigo wrote:
> >> hi all ..
> >> 
> >> i'd like to move libknotificationareaitem somewhere that apps can get to it 
> >> for 4.3, before looking at moving the actual class into libkdeui for 4.4.
> >> 
> >> is there any guidance on where it could go, how it should be installed, etc? 
> >> right now i'm thinking of putting the headers in knotificationarea/, but half 
> >> of me wonders if a generic private/ or experimental/ include dir wouldn't be a 
> >> bad idea ...
> >> 
> >> any thoughts?
> >
> > We really don't have a policy on something like this.. to my knowledge.
> > But we could make one.
> Please don't.
> Please don't put anything in kdelibs that doesn't have a stable ABI.

> And libraries with public headers should remember to change their SONAME
> on BIC changes.

Ok, quite reasonable, but what is the problem if one of the libraries
from kdelibs does this?
> (and kdelibs should not have any changes of SONAME)

There's no "kdelibs" that has a SONAME, kdelibs consists of multiple
libs each of them having their own SONAME.

BTW, I'm not saying the above idea is good (in fact I think its the
worst solution), but I'd like to understand the bad downsides for you
packagers when one of the libraries kdelibs changes its SONAME. 


You will be divorced within a year.

More information about the kde-core-devel mailing list