RFC v2: adding a temporary, non-BC gauranteed, 'private' library

Friedrich W. H. Kossebau kossebau at kde.org
Fri Apr 24 11:20:49 BST 2009

Vrendedi, le 24 avril 2009, à 11:05, Aaron J. Seigo a écrit:
> On Friday 24 April 2009, Friedrich W. H. Kossebau wrote:
> > Jeudi, le 23 avril 2009, à 22:50, Aaron J. Seigo a écrit:
> > > the new new plan is this:
> > >
> > > svn location: extragear/libs/knotificationitem
> >
> > I really wonder if _extra_gear/libs is the right location.
> i'm not sure either (there's a ? in the techbase page on the matter, in
> fact
> :)
> i'd be fine with a new module, it would just be a bit odd since a lot of
> the time that module would be empty :)

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.

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.

> please feel free to expand the scope of the techbase page to be sensible.

Will do, just need a more complete picture before...

Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta

More information about the kde-core-devel mailing list