[gentooppc-user] Fwd: [gentoo-user] RFC: KDE 'child' packages (separate ebuilds for konqueror kmail etc.)

[Calum Selkirk]

----- Forwarded message from Dan Armak <danarmak@g.o> -----

> Date: Mon, 13 May 2002 13:01:44 +0300
> From: Dan Armak <danarmak@g.o>
> Reply-To: gentoo-user@g.o
> To: gentoo-dev@g.o, gentoo-user@g.o
> Subject: [gentoo-user] RFC: KDE 'child' packages (separate ebuilds for konqueror kmail etc.)
> X-Mailer: KMail [version 1.4]

> Hello everyone,
>
> During the last week I've been working on separating the kde-base/* packages
> into 'child' packages, a feature requested by some people.  For example,
> instead of kdenetwork we'd have separate kmail, knode, kppp etc. ebuilds. The
> actual eclass framework to do this is ready.
>
> However, there is a problem. A 'parent' package (e.g. kde-base/kdenetwork)
> will still exist since most people will want to merge all of it. There are
> two ways to go:
>
> 1. The parent and child packages will not be related. They will overwrite each
> other's files. This is unacceptable.
>
> 2. The parent package will depend on all of its children and install nothing
> itself. Like kde-base/kde depends on kdebase kdenetwork etc., so will
> kde-base/kdenetwork depend on net-www/konqueror, net-mail/kmail etc. This is
> the approach I've taken so far.
>
> The problem is that while every 'child' package only compiles and installs the
> relevant files, it still needs to run the complete configure script of its
> parent package. In the admittedly worst-case example of kdebase, the script
> takes ~1.5 minutes to execute on my P3-900. kdebase has 39 child packages, so
> emerging kdebase with the new setup (i.e. emerging all child packages) will
> take about an hour longer than emerging a monolithic kdebase takes now -
> worse for slower computers.
>
> Most users won't accept this tradeoff of compile time for flexibility. So if
> you have an alternative solution, please suggest it. Otherwise there won't be
> any kde child packages. Speak now or remain forever silent :-)
>