Splitting up the kde modules

[Dominique Devriese]

David Faure writes:

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

Well yes, I thought konstruct could be told to update an existing
installation. 

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

Well, IIUC, the downsides only appear when the entire kde installation
is updated or installed at the same time.  IIUC, konstruct can do both
quite satisfactory.  If not, I don't think it's hard to write a script
that does this.

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

I don't think it's a good idea to do such an intrusive and error-prone
operation at packaging time, time and again.

cheers
domi