and once again... a better cvs structure, clearer dependancies, more logic :-) Was: Refactoring KCM technology

[Olivier Goffart]

Le Lundi 22 Mars 2004 18:26, Alexander Neundorf a écrit :
> kdelibs: basically as it is now: something very stable, absolutely
> essential, where it is not easy to change/add things, a module which *shall
> not* be split [...]
> Maybe new features should only go into kdelibs after they have been for one
> minor release in the kdeframework module and proven to be good/useful. It
> could even have a  slower release cycle then the rest (but this probably
> doesn't make sense with the kde development style).

> kdeframework: the apps discussed here, ioslaves, and e.g. libs like kabc
> (currently in kdelibs), libkipi, taglib, maybe libkcddb,  the ical stuff
> from kdepim. This way more apps can benefit from the libraries which are
> currently in the various modules. This would resolve most dependancy
> issues. This module could/should be split by packagers into the various
> components. Maybe it could also serve as a playground for new libraries or
> new features in libraries, which might be explicitely marked as
> "experimental" and removed in later versions if they turn out to suck, or
> move to kdelibs if the kick ass and are of general use :-)

If we split theses two modules, then, i would make the distinction between  
library and binary executables.  i.e: compile dependences and run-time 
dependences

> kdebase: a set of basic applications (konsole, kate, konqy, kfind, kpdf,
> kghostview, an image viewer, kmix, ...)
>
> kdedesktop: depending on kdebase, containing kicker, kwin and stuff (listed
> above)

Ok, but why theses two module should depends each others?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040322/2dc067f9/attachment.sig>