Splitting up the kde modules (was: A humble packager's request: Retire kdeaddons.)

Dominique Devriese dominique.devriese at student.kuleuven.ac.be
Wed Feb 18 15:55:38 GMT 2004

David Faure writes:

> On Wednesday 18 February 2004 16:35, Dominique Devriese wrote:
>> By the way, do you and other people also have an opinion on the
>> proposed splitting of the kde modules into app-sized chunks ?

> Yes, and the opinion is: no.

> Think of the mess: OK I need to recompile kmail. Ah but it has a
> dependency on libkdenetwork, I'll cvs update and recompile that
> first. Oh but it also depends on libkdepim.  Oh and on mimelib. Oh
> and on libkcal, which itself needs libical.  Oh and I forgot
> libksieve.  

This can and will be automated.  Konstruct already has facilities for
this, IIUC.

> For development purposes the current dependency chain is much much
> better than any further splitting. There's kdelibs, and there are
> modules depending on it.  Simple, easy.

> I think the splitting should/could be done at packaging time: we
> could provide splitted source tarballs, with one lib/app per
> tarball. I'm sure someone (e.g. a packager) has scripts to do that,
> so if the release dude agrees he could do this splitting when
> releasing. More work for one person, less work for N
> packagers.... 

That's also an interesting idea, but I would personally prefer an
upstream split.

> but think of the people downloading source tarballs and having to
> run "./configure && make && make install" 500 times?  Good thing
> there's konstruct... I guess it would really become the only way to
> build kde from source tarballs.

Indeed, konstruct would become the recommended way to build kde from
source.  That way, it would become easier, not more difficult for
normal users.


More information about the kde-core-devel mailing list