Gentoo Archives: gentoo-ppc-user

From: Calum Selkirk <cselkirk@×××××.com>
To: gentooppc-user@g.o
Subject: [gentooppc-user] Fwd: Re: [gentoo-user] RFC: KDE 'child' packages - new direction
Date: Mon, 13 May 2002 21:42:01
----- Forwarded message from Dan Armak <danarmak@g.o> -----

> Date: Mon, 13 May 2002 21:31:33 +0300 > From: Dan Armak <danarmak@g.o> > Reply-To: gentoo-user@g.o > To: gentoo-user@g.o, gentoo-dev@g.o > Subject: Re: [gentoo-user] RFC: KDE 'child' packages - new direction > X-Mailer: KMail [version 1.4]
> Hello everyone, > > My RFC turned up many proponents as wellas opponents of the change. After an > irc discussion with the other gentoo developers, we've decided to introduce > generic "subpackage" support into portage. (Or try). > > It will take some time, and so won't be available with kde-3.0.1 (which should > be released Wednesday or Thursday, according to the original plans). But, it > will solve everything in the best way possible, enabling flexible subpackages > (in an even better way than my original idea) while eliminating the multiple > configure runs problem. > > Here's the porposal I'm posting on gentoo-core (a private developer list): > > To bring everyone up to speed: > KDE child packages as implemented so far have one big disadvantage for people > who want to emerge all of kde: the configure script has to be run for every > child packages, resulting in a big overhead (1-2 minutes to run the script, > 20-40 child packages per parent --> extra hours of compilnig time). > > I asked on -dev and -user how good/bad such a tradeoff would be, and responses > have been quite mixed so far. Not quite balanced but nearly so (more people > don't care about compile time and/or want modular packages). > > New proposal: "subpackages", much as described in the header > comments. Note that I'm not talking about "dev,run,..." subpackages mentioned > there, but about separating e.g. kdenetwork into kmail, kppp, knode... But of > course any ebuild could create any subpackages it wanted. > > Description: > Portage-related side: > 1a. An ebuild sets $SUBPACKAGELIST to a list of the subpackages it has. (Not > to confuse with $SUBPACKAGES below. Someone suggest a better pair of names > please!) > > 1b. We'll probably want subpackages to have revisions independant of their > master ebuild, so that they can be updated separately. This should be > specified here as well. Like this: > SUBPACKAGELIST="foo1 foo2-r1 foo3-r4" (foo1 is at r0) > Or any other way that'll be more comfortable for the python side to process. > Maybe with a char that can't be a part of an ebuild name, like so: > SUBPACKAGELIST="foo1:0 foo2:1 foo3:4" > Or similar. > > 2. A user can call "emerge kdenetwork:kmail,knode..." (maybe even "ebuild > kdenetwork:this,that,... action"?). A dep can also contain such a string. > > 3. The ebuild is processed in the standard fashion; a variable $SUBPACKAGES is > made available to it to indicate the subpackages requested. The ebuild is > then responsible for building and installing the packages indicated. (My > kde-child -based ebuilds can do it already.) > > 4a. In src_install, each subpackage 'foo''s files go into ${D}/foo/. > Or: > 4b. As proposed in the comments, there's an src_subpkg() function > that does: > subpkg foo # set grab's subpackage to foo > grap files/*.so # register these files as belonging to subpackage foo > grap foodir # grab a directory recursively > > 5. In /var/db/pkg/category, a record "package:subpackage" is made for every > subpackage appropriately. If I "emerge kdenetwork", records for all > subpackages will be created. > > Summary: this is excellent AFAICS. It will be easier to implement ebuild-wise > than child ebuilds (since no new separate ebuilds need be created), it won't > force people to run configure more than once when not necessary, etc. > > Summary of portage-side changes required: > - master:foo1,foo2... support in emerge command lines and dependency strings, > with $SUBPACKAGES provided to the ebuild. > - master:foo subpackage registration in /var/db/pkg with $SUBPACKAGELIST from > the ebuild taken into account (e.g. if all subpackages have been merged, a > dependency on the master ebuild is satisifed; if only some have been merged, > the master ebuild is called with the complementing $SUBPACKAGES). > - support of src_subpkg() and subpkg() and grab() functions. > > Ebuild-wise, I'll be ready a day or two after the release of such a portage. > Most of the work has already been done. > > Comments welcome! >