RFC v2: adding a temporary, non-BC gauranteed, 'private' library
Friedrich W. H. Kossebau
kossebau at kde.org
Fri Apr 24 18:36:31 BST 2009
Le Freitag, 24. April 2009, à 19:00, Aaron J. Seigo a écrit:
> On Friday 24 April 2009, Friedrich W. H. Kossebau wrote:
> > And it might not work if there are also libraries which are not behind
> > kdepimlibs in the dependendy chain, but between kdelibs and kdepimlibs.
> > Or if even parts of kdelibs might depend on it. So such a module would
> > only catch a subgroup of new libs. Hm, one should go and collect all
> > candidates, current, future and previous. I guess e.g. plasmalib
> > developers would be glad if they still could improve the API.
> yes, if nothing else, extragear/libs/ is dependency chain neutral.
No longer if you put something in it which is a (hard) dependency for kdebase
or anything else from the main modules. (And isn't it also in the chain
before extragear/apps?) Or what do you mean here?
> > Hm. Perhaps the best would be to rethink the policy for the modules. And
> > start to allow explicitely marked parts of it to be unstable with regard
> > to the next major release. No idea if packagers could solve this
> > dependencies in a sane way.
> that was my original proposal, and it was rejected.
So let's try harder ;)
It's easy to reject if you don't feel the pain. This is pain of packagers vs.
pain of developers. Is there really any packaging which still packs kdelibs
as a whole and not as a kind of metapackage?
I mean I do not hope that e.g. plasmalib is installed if one installs Okteta
inside a non-KDE desktop, as nothing Okteta needs should depend on
So we even should encourage packagers to split up kdelibs. And once this is
done, there should be a way to treat libknotificationitem different from the
So, dear packagers, is it impossible or just more work for you?
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
More information about the kde-core-devel