Gentoo Archives: gentoo-ppc-user

From: Calum Selkirk <cselkirk@×××××.com>
To: gentooppc-user@g.o
Subject: [gentooppc-user] Fwd: [gentoo-user] RFC: KDE 'child' packages (separate ebuilds for konqueror kmail etc.)
Date: Mon, 13 May 2002 07:51:00
Message-Id: 20020513124821.GI29708@panix.com
----- 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 :-) >