# FAQ Tips > Hier Suchen und Finden, Links, Tutorials >  Gentoo - ganz sauber und aktuell

## Turrican

Letztes Update: 09.09.2004

*Beschreibung*

In diesem kleinen HOWTO geht es darum, wie wir unser Gentoo-System sauber und aktuell halten.
Ich möchte euch zeigen, wie ihr gefahrlos stable und unstable Software mixen könnt (aber natürlich gilt auch hier: je mehr unstable, desto weniger gefahrlos *g*), ganz einfach und sauber updated und auch euer Gentoo davor bewahrt, zuzumüllen.
Dazu schauen wir uns jetzt erstmal die typischen Probleme an und gehen dann gemeinsam schrittweise einen Update-Vorgang unseres kompletten(!) Systems, wie er persil-frischer nicht sein könnte. 
Als Vorkenntnis reicht eigentlich das Grundwissen darüber, wie man Portage bzw. emerge bedient. Und das steht im Portage-Handbuch.

1. Einführung
2. Richtiges Installieren von Unstable-Paketen mit package.keywords
3. Deinstallieren von Programmen inkl. ihrer Abhängigkeiten mit "emerge depclean"
4. Und wenn doch mal was kaputt geht?
5. Allround-Update
Anhang A: Was ist der Unterschied zwischen "emerge PAKET", "emerge --update PAKET" und "emerge --update --deep PAKET"?
Anhang B: Nützliche Tools

----------


## Turrican

Im Portage (so heißt das große Sammelsurium an Softwarepaketen für Gentoo) gibt es so viele tolle Programme, dass man sich schnell mal zum Anschauen und Ausprobieren was installiert hat.
Und wenn es einem doch nicht gefällt, haut man es eben wieder runter.
Prinzipiell alles kein Problem, wenn es da nicht die sogenannten Abhängigkeiten gäbe.

Wer schonmal unter SUSE, Mandrake und deren Kollegen ein RPM aus dem Netz installieren wollte, kennt das Problem: Programm X will erst Programm Y haben, bevor es sich bereit erklärt zu laufen. Wozu dieses Programm Y? Meistens handelt es sich dabei um irgendwelche Bibliotheken, die der Programmierer von X benutzt hat und die nötig sind, damit X läuft. Nun ging man also bei und suchte sich das passende RPM für Y und merkte bei der Installation dann, dass Programm Y wiederum von Programm Z abhängig war... das ganze ging gerne noch ein paar Schritte so weiter und konnte einen schnell in den Wahnsinn treiben.
Das haben auch u.a. die Leute bei Gentoo gemerkt und ihr Portage-System so ausgelegt, dass bei jedem Programm im sog. Ebuild genau notiert wird, welche Abhängigkeiten erfüllt werden müssen, damit alles klappt. Wenn wir nun also obiges Programm X unter Gentoo installieren wollten, würden wir einfach _emerge programm-x_ eingeben und es würden auch automatisch (in der Reihenfolge) erst Z und dann Y heruntergeladen und installiert werden, bevor sich Portage an X heranmacht. Alles automatisch.

Nun ergibt sich folgendes Problem: Wenn wir X wieder deinstallieren, weil es uns doch nicht gefällt, bleiben Y und Z weiterhin installiert und wenn es nicht gerade zufällig ein anderes Programm gibt, welches Y und/oder Z benötigt, sind diese Abhängigkeiten nicht mehr nötig und haben eigentlich keinen weiteren Grund, noch auf unserer Festplatte zu hocken. Wenn man dieses Spielchen mit Installieren/Deinstallieren etwas intensiver betreibt, so vermüllt ruckzuck unser System.
Der eine oder andere kennt das vielleicht noch von Windows, wo zwar jedes Mini-Programm sein Uninstall mitbringt, aber dennoch die DLL-Dateien in dem Windows\System-Ordner immer mehr werden. Entgegen anders lautender Gerüchte ist man auch unter Linux vor sowas nicht gefeit.

Zum Glück gibt es da eine Menge offizieller und inoffizieller Tools, mit der wir ohne viel Stress unser System sauber halten können. Die meisten von ihnen haben ziemlichen Underground-Status und sind schlecht dokumentiert, aber neben diesem HOWTO findet ihr viele Informationen unter http://forums.gentoo.org.

----------


## Turrican

Ich behaupte mal: Kein System lässt sich so genial einfach aktuell halten wie Gentoo. "Aktuell" bedeutet dabei nicht, dass man sich ohne Sinn und Verstand jeden Unstable-Mist auf den Rechner holt und sich dann wundert, warum nichts mehr läuft, sondern dass man einfach ein wenig die Spielregeln beachtet und dafür mit einem wahnsinnig stabilen System mit leckerer, frischer Software belohnt wird.
(Achtung: Wem es ab jetzt zu schnell gehen sollte, sollte sich nochmal das bereits oben zitierte Portage-Handbuch ansehen)
Normalerweise beziehen wir unsere Pakete aus dem stabilen _x86_-Zweig. Die allerneueste, heißeste, geilste Software befindet sich immer im _~x86_-Zweig, auch Unstable-Zweig genannt. Natürlich ist auch und gerade instabile Software immer reizvoll und es ist unter Gentoo auch überhaupt kein Problem, sich in sein stabiles System das eine oder andere instabile Paket zu holen.

Das Handbuch empfiehlt dazu, folgendermaßen vorzugehen (don't try this at home, kids!):


```
# ACCEPT_KEYWORDS="~x86" emerge paketname
```

So genial das Gentoo-Handbuch auch ist, aber genau so machen wir es *NICHT!* Warum nicht?

Durch die pauschale Angabe _ACCEPT_KEYWORDS="~x86"_ werden auch sämtliche Abhängigkeiten des zu installierendes Paketes aus dem Unstable-Zweig geholt, sofern sie noch nicht installiert sind. Dieser Effekt ist prinzipiell nicht wünschenswert, da man so schnell den Überblick darüber verliert, was nun alles an instabiler Software auf unserem System installiert wird.
Wenn es desweiteren irgendwann darum geht, das komplette System upzudaten, kann man sich nur entscheiden, die neuen Pakete entweder aus dem _x86_ oder dem _~x86_-Zweig zu holen.
Entscheiden wir uns für _x86_, bedeutet das für unser installiertes _~x86_-Paket, dass es höchstwahrscheinlich mit einer niedrigeren (stabilen) Version downgegradet wird - das wollen wir natürlich nicht.
Entscheiden wir uns für _~x86_, so wird unser komplettes System auf unstable upgegradet - das kann übelst daneben gehen.
Und auch so: Wer hat schon Lust, sich zu merken, was er aus dem Stable- und was aus dem Unstable-Zweig hatte?

Es wäre also eine Mischung aus beidem sinnvoll - wir müssen Portage irgendwie mitteilen, dass es über die bisher installierten _~x86_-Pakete Buch führen soll und auch bei kompletten Systemupdates speziell und nur für diese Pakete immer die _~x86_-Schiene zu fahren.
Weil Portage das (noch) nicht kann, übernehmen wir das eben - und zwar so:

Beim ersten Mal müssen wir ein Verzeichnis erstellen:



```
# mkdir /etc/portage
```

Und dann für jedes Paket, mit dem wir künftig unstable fahren wollen - hier als Beispiel das allseits beliebte XMMS:



```
# echo "media-sound/xmms ~x86" >> /etc/portage/package.keywords
```

Vergesst diesen _ACCEPT_KEYWORDS_-Pfusch! Tippt jetzt einfach _emerge xmms_ und ihr bekommt ab jetzt IMMER die heiße unstable-Version - zumindest bis ihr die entsprechende Zeile in der _/etc/portage/package.keywords_ löscht oder auskommentiert.

----------


## Turrican

Zum Deinstallieren von Programmen empfiehlt das Handbuch:



```
# emerge unmerge paketname
```

Das ist leider nur die halbe Wahrheit - wie ich schon in der Einleitung erwähnte: Auf die Art und Weise bleiben wir auf den Abhängigkeiten sitzen.
Um diese zu beseitigen, haben wir einen sehr mächtigen, aber auch sehr gefährlichen emerge-Parameter:



```
# emerge depclean
```

Was macht _emerge depclean_?
Um das zu verstehen schauen wir uns mal folgende Datei etwas genauer an:



```
# less /var/cache/edb/world
```

Dies ist das ehrwürdige Worldfile. Hier werden sämtliche Pakete eingetragen, die wir jemals von Hand mit _emerge name_ installiert haben. Und nur diese - nicht ihre Abhängigkeiten! Insofern kann man es mit der "Liste installierter Software" unter Windows vergleichen.
_emerge depclean_ nimmt nun jeden einzelnen Eintrag dieser Liste her und berechnet dessen Abhängigkeiten. Die Summe aus Worldfile (= gewünschte, von Hand installierte Programme) und errechneter (= nötiger) Abhängigkeiten ist für _emerge depclean_ tabu. Alle anderen Pakete, die nicht in dieser Liste auftauchen, werden rigoros gekillt. Leider kommt es in der Praxis da immer wieder zu Problemen und es werden trotzdem wichtige Abhängigkeiten gelöscht. (Ist aber mit dieser Anleitung alles halb so wild. *g*)
Wie gehen wir nun am sinnvollsten vor?
Am besten hält man die "Kandidaten-Liste" für _emerge depclean_ immer so kurz wie möglich. Das macht man einfach dadurch, indem man _emerge depclean_ bei jeder Deinstallation nutzt! So kann man schnell die Kandidaten überfliegen und sehen, ob irgendetwas dabei ist, was eigentlich nicht gelöscht werden darf.
Wenn man den Verdacht haben sollte, dass _emerge depclean_ zu voreilig mit dem Löschen ist, fügt man die verdächtige Abhängigkeit vorsichtshalber einfach in das Worldfile ein. Da ist sie dann sicher.

***********
UPDATE!!* _...Danke an haSk für den Hinweis..._
Wenn euch _emerge depclean_ anzeigt, dass es "acl" deinstallieren möchte, ist Vorsicht geboten. Ich zitiere mal haSk:



> Bei der Installation von der LiveCd werden ls,mkdir etc. mit ACL Support emerged. Leider findet man darauf keinen Hinweis ...
> Wenn man nun das erste mal depclean ausfuehrt, wird ACL unemerged. Folglich ist das System erstmal "Schrott", da die coreutils nicht mehr richtig laufen.
> Ist natuerlich kein richtiger Fehler von dir. Allerdings denke ich, dass es dringend erforderlich ist, dies hinzuzufuegen
> Einfach vor dem erstem depclean
> 
> USE="-acl" emerge coreutils
> 
> Und alles ist im Lot


Ja, entweder so oder wie gesagt: Tragt "sys-apps/acl" ins Worldfile ein.
************

Umgekehrt deinstalliere ich Programme mittlerweile so, dass ich gar nicht mehr _emerge unmerge_ anwende, sondern einfach den Eintrag aus dem Worldfile lösche. Dann einmal _emerge depclean_ und das Programm ist mitsamt all seiner Abhängigkeiten weg! Einfacher geht's nicht!

----------


## Turrican

Ruhe bewahren. Das ist alles kein Act.
Sollte unser Worldfile über den Jordan gehen, so kann man mit


```
# regenworld
```

ein neues erstellen. Portage benutzt dazu die Logfiles über alle installierten und wieder deinstallierten Pakete.

Wenn _emerge depclean_ doch mal etwas wichtiges löschen sollte, dann hilft das Tool mit dem schönen Namen


```
# revdep-rebuild
```

aus dem gentoolkit-Paket. Es überprüft einfach alle Programme im Worldfile auf fehlende Bibliotheken (=> Abhängigkeiten) und emerged diese dann neu. Quasi das Gegenstück zu _emerge depclean_.
Für eine erneute Überprüfung muss man erst mal wieder den Cache löschen:


```
# rm -f ~/.revdep-rebuild*
```

Und sollte dennoch trotz allem irgendein Programm nicht mehr starten, so hilft es einfach, dieses Programm nochmal von Hand zu emergen.

----------


## Turrican

So, jetzt geht's rund.  :Wink: 
Mit den vorgestellten Mitteln bringen wir jetzt unser System auf den aktuellen Stand und misten es bei der Gelegenheit gleich mal aus.

Schritt 1:


```
# emerge sync && emerge --update --deep world
```

Hiermit werden sämtliche Pakete in unserem Worldfile mit ihren Abhängigkeiten auf den neuesten Stand gebracht! Die von uns gewünschten Unstable-Pakete werden bei Bedarf ebenfalls upgegradet, aber niemals mit einer alten stable version überschrieben.
Wenn man das ganze regelmäßig macht, dauert es auch nicht so lange...  :Wink: 
Hinterher gibt es vermutlich einen Haufen Config-Dateien, die upgedatet werden wollen, das macht man entweder mit Hilfe von _etc-update_ oder von _dispatch-conf_, auf die ich hier nicht näher eingehen werde.

Schritt 2:


```
# emerge --ask depclean
```

Wir sehen uns die Liste der angeblich überflüssigen Abhängigkeiten an und geben dann unseren Segen (oder auch nicht). Bei Unstimmigkeiten siehe den Abschnitt über _emerge depclean_.

Schritt 3: 



```
# rm -f ~/.revdep-rebuild*
# revdep-rebuild --pretend
```

Hiermit prüfen wir, ob durch _emerge depclean_ doch irgendwelche Pakete beschädigt wurden. Falls ja, starten wir _revdep-rebuild_ nochmal ohne den _--pretend_-Parameter und lassen es uns reparieren.
Sollte es Probleme geben, hilft ein profanes _emerge paket_das_nicht_will_ immer. Eigentlich. Normalerweise.  :Wink: 

Das sollte es gewesen sein! War doch gar nicht so schwer, oder?
Wenn ihr das ganze einmal täglich macht (am besten per Bashscript oder wer ganz hart ist: Cronjob), ist es schnell erledigt und ihr habt immer ein sauberes, stabiles System.

----------


## Turrican

*Anhang A: Was ist der Unterschied zwischen "emerge PAKET", "emerge --update PAKET" und "emerge --update --deep PAKET"?*

Über diese Frage habe ich mir ewig den Kopf zerbrochen und mir _--pretend_-Ausgaben ohne Ende angesehen und ich glaube, jetzt habe ich kapiert, wann man am besten was einsetzt. Vielleicht hilft es dem einen oder anderen:

_emerge PAKET_: Diesen Befehl benutzt man eigentlich nur, wenn man ein bisher nicht installiertes Paket emergen will, bzw. wenn man ein Paket GLEICHER VERSION(!) noch einmal neu emergen möchte, z.B. weil es aus irgendwelchen Gründen kaputtgegangen ist.
Sobald eine neue Version von PAKET draußen ist und man diese haben möchte, sollte man tunlichst den Parameter _--update_ mitschicken.

Zwar würde PAKET auch ohne _--update_ upgedated werden, dies ist jedoch nicht zu empfehlen, da auf diese Weise sämtliche Abhängigkeiten von PAKET nur dann in Betracht gezogen (und mit geupdated) werden, wenn das Ebuild von PAKET explizit sagt: "Hallo, ich brauche wirklich die neue Version der Abhängigkeiten". Ansonsten bleibt alles beim Alten.

_emerge --update PAKET_: Hier werden die direkten Abhängigkeiten von PAKET mitbetrachtet und sofern von ihnen eine neue Version existiert, werden sie auch gleich mit upgedated. Anders als bei _emerge PAKET_ ist es hier völlig egal, ob PAKET auf die Features der neuen Abhängigkeitsversion angewiesen ist oder ob ihm vielleicht noch die alte gereicht hätte - es wird in jedem Fall alles upgedated, was in meinen Augen eine gründlichere Methode ist. Die Abhängigkeiten auf dem neuesten Stand zu haben ist mindestens genauso wichtig wie das eigentliche Programm selbst.

Beispiel: Wir haben Mozilla 1.6 installiert und wollen jetzt den neuen Mozilla 1.7 haben. Mozilla ist abhängig von GTK+ und nehmen wir an, es gäbe auch eine neue Version von GTK+, die wir noch nicht installiert haben. Wenn dem neuen Mozilla 1.7 prinzipiell die alte Version von GTK+ reicht, so updated ein _emerge mozilla_ nur den Mozilla. _emerge --update mozilla_ würde Mozilla und GTK+ updaten.

_emerge --update --deep PAKET_: Der Königsweg des Updatens. Schicke _--deep_ mit. Immer. Hier werden (wie bei _--update_ alleine) sowohl die direkten Abhängigkeiten von PAKET betrachtet, als auch die Abhängigkeiten der Abhängigkeiten. emerge rödelt also die komplette Datenbank bis zu den Grundfesten unseres Systems durch und schaut, wo man etwas aktualisieren könnte. Wenn wir diesen Befehl konsequent anwenden, können wir sicher sein, immer die neueste Software auf unserem Rechner zu haben und wenn wir nicht zu leichtfertig mit dem _~x86_-Flag umgehen (siehe oben), läuft auch alles superstabil.

----------


## Turrican

*Anhang B: Nützliche Tools*

Es gibt da ein paar tolle Tools, die euch das Leben beim Abhängigkeiten-Check extrem erleichtern.
Ich benutze da eine Mischung aus offiziellen Tools (bekommt man für ein simples _emerge gentoolkit_) und inoffiziellen Tools, die so ein Gentoo-Crack aus den Gentoo-Foren gebastelt hat. Wahnsinn!

Die offiziellen Tools: _etcat_, _qpkg_
Die inoffiziellen Tools: dep, cruft

Fast alle sind so mächtig, dass jedes Detail zu erklären den Rahmen sprengen würde. Manpages sind auch rar gesät, aber der Parameter _--help_ ist meist sehr hilfreich. Es lohnt sich auf jeden Fall, sich die Teile mal näher anzusehen - ich bin bisher noch nicht wirklich dazu gekommen. Darum hier nur ganze simple und unelegante "Was will ich machen"-Anleitungen, vielleicht mache ich später nochmal ein Update.

"Ich will die Abhängigkeiten von Paket X wissen" - _dep paket_
"Ich will wissen, welche Programme von Paket X abhängig sind" - _qpkg -q paket_
"Ich will eine Versionsübersicht von Paket X haben" - _etcat -v paket_
"Ich will die möglichen USE-Flags von Paket X wissen" - _etcat -u paket_
"Ich will wissen, welche Dateien Paket X besitzt" - _etcat -f paket_
"Ich will wissen, zu welchem Paket Datei X gehört" - _qpkg -f datei_

_cruft_ unterscheidet sich ein wenig von den anderen Tools und ist dazu da, nicht ganze Pakete zu entdecken, sondern verwaiste Dateien, die zu keinem Paket gehören, z.B. irgendwelche Configdateien in /etc. Dazu werden sämtliche Dateien auf der Platte mit denen verglichen, die laut Portage eine "Daseinsberechtigung" haben. Die Differenz kann man sich dann in Ruhe ansehen und bei Bedarf legt man selbst Hand an.

----------

