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
> 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
> 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