Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-ppc-user
Lists: gentoo-ppc-user: < Prev By Thread Next > < Prev By Date Next >
To: gentooppc-user@g.o
From: "Calum Selkirk" <cselkirk@...>
Subject: Fwd: Re: [gentoo-user] RFC: KDE 'child' packages - new direction
Date: Mon May 13 21:43:02 2002
----- 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!

Lists: gentoo-ppc-user: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Fwd: [gentoo-user] RFC: KDE 'child' packages (separate ebuilds for konqueror kmail etc.)
Next by thread:
2.4.19-rc3 oops
Previous by date:
Fwd: [gentoo-user] RFC: KDE 'child' packages (separate ebuilds for konqueror kmail etc.)
Next by date:
2.4.19-rc3 oops

Updated Jun 17, 2009

Summary: Archive of the gentoo-ppc-user mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.