KDE 4 modules structure (again) (was: structure of kde cvs modules, was Re: libkipi in kdesupport)

[Maks Orlovich]

> 1 Get rid of all inter-module dependency problems.

Wrong. It rather creates more of them, as you have to track what relies on 
what individually, rather than at a per-module level. The thing it really can 
help with is breaking dependency cycles, but those don't seem to matter much. 
If dependencies were so easy with split modules, why all the talk about build 
scripts needing non-trivial amount of work, then? 

Clearly, the best way of getting rid of dependencies problems is to make 
everything into a single package. 

> 2 Make packagers' lives a *lot* easier by not having to split up the
>   different packages themselves.

That's only an advantage if you don't consider splitting of packages to be a 
very bad idea, which in my experience as a Mandrake (which first had 
monolythic packages, and then split them) user, it is, due to much-much 
harder maintenance and administration (plus the tendency of packagers to 
split stuff that really has 0 advantage of being split). At any rate, this is 
not an undisputably good thing at all.

>
> Possible disadvantages are:
> 1 More work for developers, but imho, with a nice set of build
>   scripts, this can be mitigated.
> 2 It would require a big move on the CVS server.  Possibly, this can
>   be combined with the move to SVN that should be coming up some time
>   soon ?
> 3 A lot of work is required for doing the move and working on the
>   build scripts.  True, but a lot of hands make light work.

4. Many applications are too small to be in separate modules. KCalc? KFloppy? 
come on!
5. Increases the clean build time   --- every single module needs to have 
configure genederate, configure run; doing this per-module is quicker than 
doing this per-application
6. Discourages developers from contributing to multiple 
applications/diminishes the community aspect of modules.

7,8: see above.

-Maksim