Wer – wie ich – für Betriebssysteme aus Redmond im US Bundesstaat Washington nicht sonderlich viel übrig hat, kann früher oder später bei GNU-Linux landen. Über Mandrake und Debian bin ich seit Ende 2002 bei Gentoo Linux gelandet, das ich heute nicht nur auf meinem Server, sondern auch auf meinem Desktop einsetze (strenggenommen die ersten paar Jahre nur auf meinem Desktop).
Das feine bei Gentoo ist, dass man das System sehr speziell auf 1. die eigene Hardware und 2. auf die eigenen Bedürfnisse in Sachen Software-Pakete abstimmern kann. Gentoo Linux ist eine Meta-Distribution mit einer BSD-ähnlichn Paketverwaltung, die alle Pakete aus den Quellen baut. Nicht bei allen Paketen ist das unbedingt zweckmäßig, ein Beispiel hierfür ist das freie Office-Paket Openoffice. Es ist strenggenommen das heftigste Paket, das mir je untergekommen ist. Es ist daher auch bei Gentoo Linux als Binärpaket erhältlich – also runterladen, installieren und benutzen.
Ich finde die Oberfläche bei dem Binärpaket allerdings grottenhässlich. Daher hab ich es schon recht lange immer aus den Quellen gebaut – um den Preis, dass das schonmal 15 Stunden und mehr gebraucht hat. Heute hab ich zwar kein “Highend” System, aber ein Athlon X2 mit je 2,4 GHz, 3 Gig RAM und eine WD Raptor Festplatte sollten da schon einiges schaffen. Trotzdem brauchte es immernoch fast 5 Stunden, um OOo aus den Quellen zu backen. Genlop -t liefert mir folgende Zeit:
app-office/openoffice-2.3.0
merge time: 4 hours, 49 minutes and 3 seconds
Dann ist mir aufgefallen, dass niemals beide Kerne meines X2 ausgelastet waren – die Last schwankte hin und her, aber mehr als vielleicht mal 105% kamen nie (ich habe immer noch jede Menge andere Sachen nebenbei laufen, was dann den zweiten Kern nutzt). Bischen rumgegoogelt, haben die Devs von den OOo ebuilds die Fähigkeit von SMP abgeschaltet. Also ran, wo die Ursache liegt und wie man das umgehen kann 
WANT_MP=”true” ist des Rätsels Lösung – damit kann man paralleles Backen erzwingen (jedenfalls da, wo es möglich ist). Also flugs OOo nochmal angeschmissen und siehe da – alles geht viel flinker, die Load stieg auf Bereiche um 5 – 6 und ich hatte 2x 99% CPU Last.
Bis das Mistding reproduzierbar nach 28 Minuten ausgestiegen ist, und sich über ein fehlendes “sax” beschwerte. Ich hab dann sax gebaut, brachte keine Hilfe, immer an der selben Stelle ist das Teil ausgestiegen.
Irgendwann hatte ich die Faxen dicke, und übereinstimmend mit anderen usern im IRC musste der Fehler in USE liegen. Auf nur einem Kern gebacken, hatte ich den Fehler nämlich nicht. Also erstmal ein –depclean, dann ein revdep-rebuild, dann quick & dirty alles bis auf cups und kde in USE rausgenommen. Die ersten 40 Minuten habe ich das noch mit angesehen, beide kerne machten Vollast, ab ins Bett. Am nächsten morgen war die Freude groß:
app-office/openoffice-2.3.0
merge time: 3 hours, 5 minutes and 28 seconds
Fazit:
Die ganze Aktion hat extrem viel Zeit gekostet und keine schnelleren binaries geliefert. Schon OOo überhaupt aus den Quellen zu bauen mag vielen sinnfrei erscheinen, aber ich wollte halt ausnutzen, was meine Schüssel so hergibt. Es hat funktioniert, ich hab mich gefreut wie ein kleines Kind und das Ooo läuft wunderbar stabil. Interessant ist, dass es auf nem Quad-Opteron (2x 2Kerne zu je 2,6 GHz) in 1:42 fertig war – skaliert also schon ziemlich gut 