[gentooppc-user] Fwd: Re: [gentoo-user] RFC: KDE 'child' packages - new direction

[Calum Selkirk]

----- 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 portage.py 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 portage.py 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!
>