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

Kevin Krammer kevin.krammer at gmx.at
Thu Apr 23 19:49:43 BST 2009

On Thursday, 2009-04-23, Andreas Pakulat wrote:
> On 23.04.09 18:09:58, Sune Vuorela wrote:
> > On 2009-04-23, Andreas Pakulat <apaku at gmx.de> wrote:
> > > 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.
> >
> > Because we have based our packaging on your (KDE's) earlier promises tha
> > kdelibs was backwards binary compatible thru all of kde4.x
> We're guaranteeing that for the public libraries of kdelibs, not for
> anything thats considered private.

Sure, I don't think there is any problem for things which are inside kdelibs.
The library might get installed but since there are no headers, nobody can 
build against it and only need symbols from the public libraries, independent 
whether any public uses one variant of a private lib or another.

However I think Aaron ask about a library which can/should be used by 
applications outside of those bounds, e.g. inside kdebase.


Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090423/a70e8525/attachment.sig>

More information about the kde-core-devel mailing list