1 |
One thing missing from this how to avoid using the spit ebuilds (i.e., |
2 |
some kind of use flag may be needed?). Even with distcc and multiple |
3 |
helpers, it only takes a few separate packages to blow the time needed |
4 |
to compile past a single package. |
5 |
|
6 |
Example on a K6-500, kdelibs took (according to genlop) 11hrs 39 mins. |
7 |
This was out of some 3 and a bit days compiling 86 packages (big update |
8 |
- mostly gnome related - see last paragraph). You say in the documents |
9 |
that a split kde will do around 100 packages in a typical update. On |
10 |
the above figures, that looks like it will blow my compile times way |
11 |
out! Not just an acceptable small amount. |
12 |
|
13 |
Is it only me that thinks this idea is crazy, as the biggest single |
14 |
criticism of gentoo is build from source compile time, especially on the |
15 |
first install where this will hit really really badly? Monolithic |
16 |
builds are not ideal and have problems of their own, but here I think |
17 |
practicality needs to come into it. Alternatively, some major fixes to |
18 |
the build system to fix the core problem (mostly the configure stage |
19 |
needs caching properly) well before this is implemented. |
20 |
|
21 |
I am not a dev, only a user, but who uses this stuff daily - and I can |
22 |
see big problems on the horizon with this for the average user on less |
23 |
than the fastest and latest hardware. I mainly use gnome (but have kde |
24 |
installed), and can attest to the fact that their multi package approach |
25 |
sucks. You get updates that fail and block other packages and you end |
26 |
up with a mixed package and broken gnome (has happened numerous times) - |
27 |
on gnome systems I keep a fluxbox (and a kde on my main desktop) install |
28 |
so I dont get caught with an unusable system. Then there is the fact |
29 |
that updates to gentoo stable usually mean multiple gnome packages |
30 |
updated - rarely is it just one or two packages. Gnome has only a |
31 |
fraction of the packages in kde, but the disadvantages of this from a |
32 |
user point of view are quite plain from experience. |
33 |
|
34 |
|
35 |
BillK |
36 |
|
37 |
*I did see the discussions on this previously and the MIPS peoples |
38 |
objection to it, but from my own figures and experience, I dont want to |
39 |
go the split ebuild path on any of my x86 systems, only one of which |
40 |
could be called "fast". By the time confcache comes out I may have |
41 |
nearly finished compiling the first split ebuilds. |
42 |
|
43 |
On Wed, 2005-03-16 at 22:16 +0200, Dan Armak wrote: |
44 |
> Hello, |
45 |
> |
46 |
> I'm unmasking the KDE 3.4.0 ebuilds now, and wanted to remind anyone who |
47 |
> missed this fact that starting with this release, we're providing split |
48 |
> ebuilds. That means you can 'emerge konqueror kmail' rather than 'emerge |
49 |
> kdebase kdepim'. Details and FAQ at |
50 |
> http://www.gentoo.org/doc/en/kde-split-ebuilds.xml. |
51 |
> |
52 |
|
53 |
-- |
54 |
gentoo-dev@g.o mailing list |