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