KDE 3.5 Gentoo ebuilds

Is it me, or is somebody just not thinking?  It seems like Gentoo has a beef against monolithic packages like KDE and X.org.  The recent builds of these have been broken up into (as many as) hundreds of separate ebuilds — in the case of KDE, instead of the monolithic kdepim for example, each package that came with kdepim now has its own ebuild (same with kdeaddons, kdegraphics, etc).  Which is all very well, except that upstream still distributes the source monolithically…

I’ve noticed the following when emerging the new KDE 3.5…

>>> Emerging (18 of 275) kde-base/ksystraycmd-3.5.1 to /
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking kdebase-3.5.1.tar.bz2 ;-)
>>> Unpacking source...
>>> Extracting from tarball...
>>> Source unpacked.

One thing is that this emerge (an emerge world, btw) comprises 275 operations, most of which are KDE.  That’s okay, KDE is big.  But each and every ebuild is working on the kdebase tarball — checking the MD5, unzipping, extracting.  Presumably when it eventually gets to the other KDE components it will leave the kdebase tarball alone and move on to each of the others…

Hopefully it’s only untarring the directory for the package being compiled (you can do that with tar, right?).  It’s still a lot of digesting and unzipping though!  Surely it’s safe to assume that I’ll want more than just one package out of the tarball, so the whole thing could be unwound someplace and linked into at compile-time…

Maybe the overhead of managing that is not warranted (after all, we all have octo-core 24GHz AMD chips in our PCs now, don’t we)…

Leave a comment