[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: A humble packager's request: Retire kdeaddons.
From:       Dominique Devriese <dominique.devriese () student ! kuleuven ! ac ! be>
Date:       2004-02-18 15:51:07
Message-ID: 87u11owfmc.fsf () student ! kuleuven ! ac ! be
[Download RAW message or body]

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.  And if you're going to say: put all those together with
> kmail, then we need to put korganizer and knode there too, since
> they use the same libs. And in the end you end up with.... kdepim,
> exactly as it is today.

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

> -- David Faure, faure@kde.org, sponsored by Trolltech to work on
> KDE, Konqueror (http://www.konqueror.org), and KOffice
> (http://www.koffice.org).

[prev in list] [next in list] [prev in thread] [next in thread]