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

List:       kde-core-devel
Subject:    Re: Splitting up the kde modules (was: A humble packager's request:
From:       David Faure <faure () kde ! org>
Date:       2004-02-18 16:00:44
Message-ID: 200402181700.44647.faure () kde ! org
[Download RAW message or body]

On Wednesday 18 February 2004 16:55, Dominique Devriese wrote:
> 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.

I'm talking about people working on the CVS.
The current modules exist primarily to make life easier for developers
and other people compiling the CVS.

Sure, kde-build can build all of CVS. But when you just want to work on one
thing you don't necessarily want to recompile everything all the time.

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

Aren't tarballs upstream enough? If you only care about packaging, 
why is it a problem if developers prefer another way of working, as long
as you get splitted 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]