Anzeige:
Ergebnis 1 bis 8 von 8

Thema: Gentoo - ganz sauber und aktuell

  1. #1
    Turrican
    Gast

    Gentoo - ganz sauber und aktuell

    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
    Geändert von Turrican (09.09.04 um 21:07 Uhr)

  2. #2
    Turrican
    Gast

    1. Einführung

    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.

  3. #3
    Turrican
    Gast

    2. Richtiges Installieren von Unstable-Paketen mit package.keywords

    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!):
    Code:
    # 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:

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

    Code:
    # 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.
    Geändert von Turrican (09.09.04 um 21:21 Uhr)

  4. #4
    Turrican
    Gast

    3. Deinstallieren von Programmen inkl. ihrer Abhängigkeiten mit "emerge depclean"

    Zum Deinstallieren von Programmen empfiehlt das Handbuch:

    Code:
    # 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:

    Code:
    # emerge depclean
    Was macht emerge depclean?
    Um das zu verstehen schauen wir uns mal folgende Datei etwas genauer an:

    Code:
    # 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:
    Zitat Zitat von 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!
    Geändert von Turrican (09.09.04 um 21:06 Uhr)

  5. #5
    Turrican
    Gast

    4. Und wenn doch mal was kaputt geht?

    Ruhe bewahren. Das ist alles kein Act.
    Sollte unser Worldfile über den Jordan gehen, so kann man mit
    Code:
    # 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
    Code:
    # 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:
    Code:
    # 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.

  6. #6
    Turrican
    Gast

    5. Allround-Update

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

    Schritt 1:
    Code:
    # 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...
    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:
    Code:
    # 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:

    Code:
    # 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.

    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.

  7. #7
    Turrican
    Gast

    Anhang A

    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.

  8. #8
    Turrican
    Gast

    Anhang B

    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.

Ähnliche Themen

  1. 2.6: TV-Wiedergabe ruckelt
    Von DarkSorcerer im Forum Fernsehen
    Antworten: 19
    Letzter Beitrag: 28.04.07, 19:33
  2. gentoo + Grub
    Von Da.Bull im Forum System installieren und konfigurieren
    Antworten: 102
    Letzter Beitrag: 27.07.04, 14:12
  3. Gentoo 2004.1
    Von Kip im Forum Neue Programme/Versionen
    Antworten: 19
    Letzter Beitrag: 05.06.04, 17:21
  4. gentoo --> slackware - wie sauber bleibt das system
    Von Säck im Forum System installieren und konfigurieren
    Antworten: 27
    Letzter Beitrag: 03.03.04, 13:18
  5. Ich will Gentoo draufmachen
    Von Linuxanfänger17 im Forum System installieren und konfigurieren
    Antworten: 7
    Letzter Beitrag: 25.10.03, 02:08

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •