One thing missing from this how to avoid using the spit ebuilds (i.e.,
some kind of use flag may be needed?).  Even with distcc and multiple
helpers, it only takes a few separate packages to blow the time needed
to compile past a single package.

Example on a K6-500, kdelibs took (according to genlop) 11hrs 39 mins.
This was out of some 3 and a bit days compiling 86 packages (big update
- mostly gnome related - see last paragraph).  You say in the documents
that a split kde will do around 100 packages in a typical update.  On
the above figures, that looks like it will blow my compile times way
out!  Not just an acceptable small amount.

Is it only me that thinks this idea is crazy, as the biggest single
criticism of gentoo is build from source compile time, especially on the
first install where this will hit really really badly?  Monolithic
builds are not ideal and have problems of their own, but here I think
practicality needs to come into it.  Alternatively, some major fixes to
the build system to fix the core problem (mostly the configure stage
needs caching properly) well before this is implemented.

I am not a dev, only a user, but who uses this stuff daily - and I can
see big problems on the horizon with this for the average user on less
than the fastest and latest hardware.  I mainly use gnome (but have kde
installed), and can attest to the fact that their multi package approach
sucks.  You get updates that fail and block other packages and you end
up with a mixed package and broken gnome (has happened numerous times) -
on gnome systems I keep a fluxbox (and a kde on my main desktop) install
so I dont get caught with an unusable system.  Then there is the fact
that updates to gentoo stable usually mean multiple gnome packages
updated - rarely is it just one or two packages.  Gnome has only a
fraction of the packages in kde, but the disadvantages of this from a
user point of view are quite plain from experience.


BillK

*I did see the discussions on this previously and the MIPS peoples
objection to it, but from my own figures and experience, I dont want to
go the split ebuild path on any of my x86 systems, only one of which
could be called "fast".  By the time confcache comes out I may have
nearly finished compiling the first split ebuilds.

On Wed, 2005-03-16 at 22:16 +0200, Dan Armak wrote:
> Hello,
> 
> I'm unmasking the KDE 3.4.0 ebuilds now, and wanted to remind anyone who 
> missed this fact that starting with this release, we're providing split 
> ebuilds. That means you can 'emerge konqueror kmail' rather than 'emerge 
> kdebase kdepim'. Details and FAQ at 
> http://www.gentoo.org/doc/en/kde-split-ebuilds.xml. 
> 

--
gentoo-dev@g.o mailing list