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

[Friedrich W. H. Kossebau]

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 
plasmalibs.
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 
rest.
So, dear packagers, is it impossible or just more work for you?

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