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 |