| 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 |
Archives