| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hello everyone, |
| 5 |
|
| 6 |
My RFC turned up many proponents as wellas opponents of the change. After an |
| 7 |
irc discussion with the other gentoo developers, we've decided to introduce |
| 8 |
generic "subpackage" support into portage. (Or try). |
| 9 |
|
| 10 |
It will take some time, and so won't be available with kde-3.0.1 (which should |
| 11 |
be released Wednesday or Thursday, according to the original plans). But, it |
| 12 |
will solve everything in the best way possible, enabling flexible subpackages |
| 13 |
(in an even better way than my original idea) while eliminating the multiple |
| 14 |
configure runs problem. |
| 15 |
|
| 16 |
Here's the porposal I'm posting on gentoo-core (a private developer list): |
| 17 |
|
| 18 |
To bring everyone up to speed: |
| 19 |
KDE child packages as implemented so far have one big disadvantage for people |
| 20 |
who want to emerge all of kde: the configure script has to be run for every |
| 21 |
child packages, resulting in a big overhead (1-2 minutes to run the script, |
| 22 |
20-40 child packages per parent --> extra hours of compilnig time). |
| 23 |
|
| 24 |
I asked on -dev and -user how good/bad such a tradeoff would be, and responses |
| 25 |
have been quite mixed so far. Not quite balanced but nearly so (more people |
| 26 |
don't care about compile time and/or want modular packages). |
| 27 |
|
| 28 |
New proposal: "subpackages", much as described in the portage.py header |
| 29 |
comments. Note that I'm not talking about "dev,run,..." subpackages mentioned |
| 30 |
there, but about separating e.g. kdenetwork into kmail, kppp, knode... But of |
| 31 |
course any ebuild could create any subpackages it wanted. |
| 32 |
|
| 33 |
Description: |
| 34 |
Portage-related side: |
| 35 |
1a. An ebuild sets $SUBPACKAGELIST to a list of the subpackages it has. (Not |
| 36 |
to confuse with $SUBPACKAGES below. Someone suggest a better pair of names |
| 37 |
please!) |
| 38 |
|
| 39 |
1b. We'll probably want subpackages to have revisions independant of their |
| 40 |
master ebuild, so that they can be updated separately. This should be |
| 41 |
specified here as well. Like this: |
| 42 |
SUBPACKAGELIST="foo1 foo2-r1 foo3-r4" (foo1 is at r0) |
| 43 |
Or any other way that'll be more comfortable for the python side to process. |
| 44 |
Maybe with a char that can't be a part of an ebuild name, like so: |
| 45 |
SUBPACKAGELIST="foo1:0 foo2:1 foo3:4" |
| 46 |
Or similar. |
| 47 |
|
| 48 |
2. A user can call "emerge kdenetwork:kmail,knode..." (maybe even "ebuild |
| 49 |
kdenetwork:this,that,... action"?). A dep can also contain such a string. |
| 50 |
|
| 51 |
3. The ebuild is processed in the standard fashion; a variable $SUBPACKAGES is |
| 52 |
made available to it to indicate the subpackages requested. The ebuild is |
| 53 |
then responsible for building and installing the packages indicated. (My |
| 54 |
kde-child -based ebuilds can do it already.) |
| 55 |
|
| 56 |
4a. In src_install, each subpackage 'foo''s files go into ${D}/foo/. |
| 57 |
Or: |
| 58 |
4b. As proposed in the portage.py comments, there's an src_subpkg() function |
| 59 |
that does: |
| 60 |
subpkg foo # set grab's subpackage to foo |
| 61 |
grap files/*.so # register these files as belonging to subpackage foo |
| 62 |
grap foodir # grab a directory recursively |
| 63 |
|
| 64 |
5. In /var/db/pkg/category, a record "package:subpackage" is made for every |
| 65 |
subpackage appropriately. If I "emerge kdenetwork", records for all |
| 66 |
subpackages will be created. |
| 67 |
|
| 68 |
Summary: this is excellent AFAICS. It will be easier to implement ebuild-wise |
| 69 |
than child ebuilds (since no new separate ebuilds need be created), it won't |
| 70 |
force people to run configure more than once when not necessary, etc. |
| 71 |
|
| 72 |
Summary of portage-side changes required: |
| 73 |
- - master:foo1,foo2... support in emerge command lines and dependency strings, |
| 74 |
with $SUBPACKAGES provided to the ebuild. |
| 75 |
- - master:foo subpackage registration in /var/db/pkg with $SUBPACKAGELIST from |
| 76 |
the ebuild taken into account (e.g. if all subpackages have been merged, a |
| 77 |
dependency on the master ebuild is satisifed; if only some have been merged, |
| 78 |
the master ebuild is called with the complementing $SUBPACKAGES). |
| 79 |
- - support of src_subpkg() and subpkg() and grab() functions. |
| 80 |
|
| 81 |
Ebuild-wise, I'll be ready a day or two after the release of such a portage. |
| 82 |
Most of the work has already been done. |
| 83 |
|
| 84 |
Comments welcome! |
| 85 |
|
| 86 |
- -- |
| 87 |
Dan Armak |
| 88 |
Gentoo Linux developer (KDE) |
| 89 |
Matan, Israel |
| 90 |
-----BEGIN PGP SIGNATURE----- |
| 91 |
Version: GnuPG v1.0.7 (GNU/Linux) |
| 92 |
|
| 93 |
iD8DBQE84AaFUI2RQ41fiVERAkNFAJ9AZeNpdlq0B2Tii768ak/tqk4xJQCfdzeY |
| 94 |
+6WAFDe8UD9Xh2ouIuCDKvs= |
| 95 |
=iZXH |
| 96 |
-----END PGP SIGNATURE----- |
Archives