Re: [gentoo-dev] Segregating KDE?

[Dan Armak]

On Sunday 19 September 2004 21:08, Simone Gotti wrote:
> By the way, I think that it's possible to split EVERY kde program/libs in a
> single package, this can be possibile by heavily patching the Makefiles
> like you've said so they can link to an installed lib instead of the local
> one, this libs will be a dep of the program and it should be of course a
> different ebuild.
It's certainly possible. I even think (well, intuition...) the patching won't 
have to be very heavy.

>
> I'm already giving a little help to caleb and carlo on the kde ebuilds and
> if ypu and they think that a lot of people thinks that having single kde
> programs instead of the standard modules will be a better idea I'll be VERY
> happy to start hacking on this. My great fear is that it will slow down the
> development of the ebuilds because this bring to a lot of additional work!
> Think that probably the Makefile's patches must be changed on every kde
> major release.
>
> All I need is to know if you (gentoo kde developers) are really interested
> on this work. Let me know!
As I said, I'm definitely going to try making this work, but won't have real 
time until the weekend after next (and most days after that, hopefully), so 
you can beat me to it.

I've just tried the confcache patch. It's integrated into portage .51 cvs 
snapshots here http://dev.gentoo.org/~ferringb/ebuild-daemon/51-pre20-cvs/ - 
they apparently include other highly experimental stuff and the last one has 
some bugs already fixed in cvs, so be in touch with #gentoo-portage if using 
these.  To enable confcache, add 'confcache' to FEATURES and change the kde 
ebuilds to use econf rather than call configure directly. This results in the 
kde.eclass attached - the change is trivial, but as I'm on rsync not cvs atm, 
I can't make a diff immediately, sorry. The change for split packages should 
also be on the order of a five-liner in kde.eclass, apart from the makefile 
changes.

On my athlon xp 2600, this makes the kdelibs configure run go down from 66 
seconds to 28 seconds. At least 10-12 seconds of each of these two numbers is 
due to makefile generation, which will be very much reduced in split-up 
ebuilds, so we get 54 sec -> 16 sec, or a 5x improvement.

Also, on slower machines a far larger percent of time spent in (non-cached) 
configure is due to slow compilations rather than (as here) IO, so the 
benefit will be even greater there. This indicates we should at least 
reevluate the emerge performance factor of splitting up the kde ebuilds.

Using my old rough formula, we get:
17 configure scripts (before splitting ebuilds) --> 20-60 minutes total 
running time
splitting up --> >=220 packages (? but at least that many, I believe)
splitting up without confcache --> 220-660 minutes, i.e. 3.6-11 hours, total 
running time (clearly unacceptable)
splitting up with confcache --> about 15-20% of above, i.e. 1-2.2 hours total 
running time

According to these numbers, if we both add confcache and split the ebuilds, 
the total time for emerging all or nearly all of kde will increase by 0.6-1.2 
hours, plus the overhead from running the emerge cycle 200 more times, which 
I hope is relatively negligible (a few minutes?). 

Compared with the benefits (to those who don't want all of kde, and 
considering that >95% of people typing 'emerge kde' to save package selection 
time don't really want kdetoys and kdeedu and such, this seems on first sight 
to be a reasonable tradeoff for the added functionality. What do you think, 
everyone? Also note that my benchmarking is hardly scientific, so I'd be glad 
if someone bothered to repeat it and compare his results to mine.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951