| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hello everyone, |
| 5 |
|
| 6 |
This is my plan :-) |
| 7 |
|
| 8 |
I understand now that so many people have requested it that splitting the |
| 9 |
packages (in a way that doesn't harm those who want the full packages!) is an |
| 10 |
important feature. I wanted to explain to everyone what my outlook on this |
| 11 |
is, so I'm quoting my comments from bug #11123 (including one I added just |
| 12 |
now): |
| 13 |
|
| 14 |
- ------- Additional Comment #1 From Dan Armak 2002-11-29 13:46 ------- |
| 15 |
This has been discussed before. Formally if you want to call it that - on the |
| 16 |
mailing lists at least. |
| 17 |
|
| 18 |
There are two ways of implementing this. |
| 19 |
|
| 20 |
Under the current portage architecture, we'd need to use separate, autonomous |
| 21 |
ebuilds for every 'subpackage'. This however raises a problem: |
| 22 |
|
| 23 |
A kde configure script takes as much as a minute or more to run. Today when |
| 24 |
you emerge all of kde you run ~17 configure scripts, i.e. as much as 20 |
| 25 |
minutes goes there (of course everything depends on the speed of the |
| 26 |
machine). |
| 27 |
If all kde-base packages are split into separate subpackage ebuilds, you'll |
| 28 |
get hundreds of subpackages (200+). That means an extra 200 minutes -- 3.5 |
| 29 |
hours -- added to the compilation time of all of KDE. And most people do want |
| 30 |
the whole of kde. This is unacceptable. |
| 31 |
|
| 32 |
There were various proposals of caching the configuration info, or sharing it |
| 33 |
somewhere in /var/tmp. But all that is complex, inelegant and unpleasant to |
| 34 |
implement and maintain. |
| 35 |
|
| 36 |
The other possibility is having a single ebuild provide real 'subpackages' any |
| 37 |
combination of which could be emerged by request. However there would only be |
| 38 |
a single workdir, so unless you deleted /var/tmp/portage in the middle of it, |
| 39 |
'emerge kde' would run configure a minimal amount of times. |
| 40 |
|
| 41 |
However this requires new portage features: fex. keeping in /var/db/pkg the |
| 42 |
info of which subpackages are installed, and recognizing a variables/use flag |
| 43 |
for that purpose. |
| 44 |
|
| 45 |
Someday I hope this can be done. |
| 46 |
|
| 47 |
- ------- Additional Comment #8 From Dan Armak 2003-01-29 08:17 ------- |
| 48 |
|
| 49 |
It is not a problem to make an ebuild compile a subset of all available |
| 50 |
subpackages. <snip> |
| 51 |
|
| 52 |
Now the best solution IMHO would be to implement 'subpackages' as i described |
| 53 |
before. An ebuild could then divide the files it installs into a number of |
| 54 |
'subpackages'. If the user requested merging certain subpackages, the ebuild |
| 55 |
would (should) be smart enough to take only the minimal action required to |
| 56 |
compile those subpackages. And if the user requested everything (as in an |
| 57 |
ordinary emerge command), the ebuild would be smart enough not to repeat |
| 58 |
actions (ie not to run configure more than once). |
| 59 |
|
| 60 |
This obviously needs portage-side support and so must come after the present |
| 61 |
(pre-1.4-release) feature freeze ends. I'll try to add such support then, |
| 62 |
meanwhile I'm dealing with bugs only... |
| 63 |
|
| 64 |
- -- |
| 65 |
Dan Armak |
| 66 |
Gentoo Linux developer (KDE) |
| 67 |
Matan, Israel |
| 68 |
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key |
| 69 |
-----BEGIN PGP SIGNATURE----- |
| 70 |
Version: GnuPG v1.2.1 (GNU/Linux) |
| 71 |
|
| 72 |
iD8DBQE+N+HnUI2RQ41fiVERAjWDAJ9+1y4m0Uaf9mWVBHu3bz+FIjYRjQCbBil/ |
| 73 |
ac43MZk6sGapo8K2REuWBBU= |
| 74 |
=ozoD |
| 75 |
-----END PGP SIGNATURE----- |
| 76 |
|
| 77 |
|
| 78 |
-- |
| 79 |
gentoo-dev@g.o mailing list |
Archives