Tag: Aptitude

Posted on

Einführung in aptitude, apt-get, apt-cache und dpkg

Für erfahrene Debianbenutzer sicher kein Thema was brandneue Informationen verspricht, als Fußnote ist es mir dennoch wichtig. Mich hat es früher immer geärgert, dass man das scheinbar Selbstverständliche erst einmal mühsam im Internet nachforschen musste. Nun kann ich nicht versprechen, dass ich nicht an anderer Stelle in diesem Blog es genauso gemacht habe, aber zumindest bei meiner Anleitung zur Debian-Netzinstallation möchte ich eine "triviale" Sache nicht übergehen - das Paketmanagement.
Bekanntlich ist es die große Stärke von Linux, die gesamte Software aus einer Hand, sprich einem Repositorium, herunterladen und installieren zu können. Debian nennt das Werkzeug dazu "Advanced Packaging Tool" oder kurz APT. Für APT gibt es verschiedene Paketmanager, Frontends und Werkzeuge, die diese wiederkehrenden Prozesse vereinfachen sollen. Natürlich gibt es auch grafische wie Synaptic. Mein Favorit ist jedoch Aptitude. Aptitude kombiniert einige Merkmale von apt-get und apt-cache, was es, denke ich, einfacher macht sich die Befehle zu merken. Auf der anderen Seite gibt es einige Alleinstellungsmerkmale von apt-get und apt-cache. Um die Verwirrung komplett zu machen, existiert noch dpkg, welches zur eigentlichen Paketverwaltung auf dem lokalen System von den Frontends genutzt wird.

Paketquellen anpassen

Bevor man neue Software installieren möchte, muss man die Quellen in /etc/apt/sources.list an seine Anforderungen anpassen. Entscheidend dabei ist, für welches Debian man sich entschieden hat.

deb http://ftp.de.debian.org/debian stable main contrib non-free
deb-src http://ftp.de.debian.org/debian stable main
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb http://ftp.de.debian.org/debian unstable main

Die Quelle für Binärpakete wird mit deb eingeleitet. Danach folgt die URL des Spiegelservers. Schließlich definiert man mit stable, testing oder unstable, welchen Debianzweig man verwenden möchte. Als Alternative lassen sich auch die Codenamen
squeeze, wheezy und sid an dieser Stelle eintragen, die sich natürlich in der Zukunft ändern werden. Die Verwendung des Codenamens bedeutet nur, dass man dieser Version durch die verschiedenen Stadien des Veröffentlichungszyklus folgen möchte. Wheezy wandert z.B. jetzt von Testing in ein paar Monaten nach Stable und ist in ca. 2,5 Jahren dann nur noch Oldstable bis es ein weiteres Jahr später überhaupt keinen Support mehr geben wird.

Nach der Definition der Debianversion bestimmt man noch aus welchen der drei Repos man Pakete beziehen möchte. Das sind main, contrib und non-free. In main befindet sich ausschließlich freie Software nach den Debian Free Software Guidelines (DFSG). In contrib existiert ebenfalls nur freie Software, die aber zum Funktionieren noch eine unfreie Komponente benötigt, z.B. ist der Server von Cube 2:Sauerbraten frei, die Medieninhalte hingegen stehen teilweise unter unfreien Lizenzen. In non-free befinden sich konsequenterweise Daten und Software, die nicht mit den DFSG vereinbar sind.

Grundlagen

Paketcache updaten

aptitude update oder apt-get update

Pakete suchen

aptitude search Ausdruck oder apt-cache search Ausdruck

Paketinformationen anzeigen

aptitude show Paketname oder apt-cache show Paketname

Pakete installieren

aptitude install Paketname oder apt-get install Paketname

Pakete entfernen

aptitude remove Paketname oder apt-get remove Paketname

Pakete inkl. Konfigurationsdateien entfernen

aptitude purge Paketname oder apt-get purge Paketname

System auf den neusten Stand bringen

aptitude safe-upgrade oder apt-get upgrade

System auf eine andere Version upgraden (z.B. Squeeze->Wheezy)

aptitude full-upgrade oder apt-get dist-upgrade

Den Quellcode herunterladen

apt-get source mutt


Wenn man in der /etc/apt/sources.list mit der Zeile deb-src den Zugang zu den Quelldateien freigeschaltet hat, ist es möglich mit apt-get den Quellcode herunterzuladen. Das Alleinstellungsmerkmal, das apt-get bisher von aptitude unterscheidet.

dpkg

Dpkg wird nur bei der Installation oder Deinstallation lokaler Dateien direkt aufgerufen, wenn man also z.B. ein Paket selbst erstellt hat

dpkg -i Paketname
dpkg -P Paketname

Oft viel interessanter sind Optionen wie
// listet alle installierten Pakete auf
dpkg -l
// listet Paket mutt mit ein paar Informationen auf
dpkg -l mutt
// Gibt die Orte der Dateien aus, die sich im Paket mutt befinden
dpkg -L mutt
// Sucht nach dem Muster/Ausdruck mutt im gesamten Paketcache
dpkg -S mutt
Gerade auf älteren Rechner ist der direkte Aufruf von dpkg, um mehr Informationen über den Paketzustand herauszufinden, gefühlt schneller als mit aptitude.

Was ich 99% meiner Zeit mit aptitude mache

// Täglich
aptitude update
aptitude safe-upgrade
// Wenn ich Testing oder Unstable benutze, die Konsequenzen kenne und einen Konflikt auflösen möchte
aptitude update
aptitude full-upgrade
// Programme installieren, z.B. htop, ncdu und cmus
aptitude update
aptitude install htop ncdu cmus
// Die Programme htop, ncdu und cmus mit Konfigurationsdateien entfernen
aptitude purge htop ncdu cmus
// Alle Pakete der Sektion web und games auflisten
aptitude search '~sweb'
aptitude search '~sgames'

Das wars?

Jep. Nicht vergessen immer mal die TAB-Taste zu drücken ;), aber ansonsten ist es das. Solltet ihr keine Root-Rechte haben, könnt ihr auch mit der angehängten Option -s die einzelnen Optionen nur simulieren.
aptitude install htop -s
Ansonsten hilft ab und an ein
aptitude autoclean,
damit der Paketcache nicht zu viel Platz auf der Festplatte belegt. Diese Befehle sollten vollkommen ausreichend sein, um das eigene Linuxsystem erweitern und gestalten zu können. Alle weiteren Ideen mit Aptitude habe ich unter dem Stichwort Aptitude verschlagwortet. Für mehr Informationen zu den einzelnen Paketmanagern hilft wie immer man weiter.

Posted on

Aufräumtipps Teil II: Automatisch installierte Pakete mit Debian und Ubuntu entfernen

Hier ist ein weiterer Artikel zum Thema Aufräumen mit Debian und Ubuntu, der sich an den letzten Artikel nahtlos anschließt. Raphaël Hertzog hat in seinem englischen Blog daraus eine kleine Serie gemacht, die ich so interessant fand, dass ich sie in Deutsch hier festhalten wollte.
In diesem Fall geht es um automatisch installierte Pakete und wie man sie wieder loswerden kann.
Jeder kennt das sicherlich bei Debian und Ubuntu, wenn man apt-get oder aptitude benutzt und folgende Ausgabe im Terminal zu sehen ist.

apt-get install claws-mail
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
claws-mail-i18n libcompfaceg1 libetpan15 libpisock9
Vorgeschlagene Pakete:
claws-mail-doc gedit kwrite mousepad nedit claws-mail-tools jpilot pilot-link kpilot gnome-pilot evolution sylpheed
Die folgenden NEUEN Pakete werden installiert:
claws-mail claws-mail-i18n libcompfaceg1 libetpan15 libpisock9
0 aktualisiert, 5 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
Es müssen 4.356 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 11,3 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?

Die "folgenden zusätzlichen Pakete" sind die automatisch installierten Pakete, die man zwar nicht explizit installieren wollte, die aber notwendig sind, damit das ursprüngliche Programm, claws-mail, reibungslos funktioniert.
Aptitude stellt für diese Pakete ein Extrafeld zur Verfügung.

Mit aptitude show claws-mail-i18n findet man z.B.

Automatically installed: yes

Je nachdem welches Frontend man bevorzugt, kann man entweder mit

apt-mark showauto

oder

aptitude search ~M


automatisch installierte Pakete finden. Während aptitude diese zusätzlich installierten Pakete mit aptitude remove claws-mail oder aptitude purge claws-mail entfernen würde, benachrichtigt apt-get einem nur über diese Möglichkeit. Tatsächlich muss man noch apt-get autoremove ausführen, damit apt-get diese automatisch installierten Pakete wieder entfernt.
Der Trick mit diesem Feature ist der folgende. Man kann zum einen Software als automatisch installiert markieren.

apt-mark markauto cmus

oder

aptitude markauto cmus

Damit erkennt der Paketmanager, dass diese Pakete nicht mehr gebraucht werden, sofern kein weiteres Paket mehr davon abhängt. Auf meinem System würde der letzte Befehl z.B. sofort zur Deinstallation von cmus führen.
Häufiger hingegen kommt es vor, dass plötzlich ganze Desktopumgebungen deinstalliert werden sollen, wenn man nur daran interessiert ist Teile der Gnome-Desktopumgebung zu entfernen.
Der "Trick" besteht auch hier darin, dem Paketmanager zu signalisieren, was man behalten möchte und was nicht. Stellt man fest, dass Metapakete oder wichtige Software wie gnome-session oder gnome-shell entfernt werden sollen, kann man mit

apt-mark unmarkauto gnome-session gnome-shell oder
aptitude unmarkauto gnome-session gnome-shell


dem System deutlich machen, dass man diese Pakete behalten möchte. Mit dieser Methode lässt sich gezielt automatisch installierte Software entfernen, ohne dass die ganze Distribution dadurch in Mitleidenschaft gezogen wird.
Zusammen mit den weiteren Hilfsmittel ist das eine gute Ausgangsbasis sein Debian minimal und sauber zu halten.

Posted on

Drei Aufräumtipps mit Aptitude für Debian und Ubuntu

Ich stelle gerne von Zeit zu Zeit ein paar Tipps und Tricks vor, wie man mit Debians Systemwerkzeugen sein eigenes Betriebssystem sauber und minimal halten kann. Zum Installieren und Entfernen von Software benutze ich am liebsten Aptitude.
Nun bin ich mit Sicherheit nicht der Einzige, der Debian und Ubuntu benutzt. Andere Leute wie z.B. Raphaël Hertzog haben in der Vergangenheit schon viele nützliche Beiträge hierzu geschrieben. Da er selbst Debianentwickler ist und einige essentielle Werkzeuge für Debian mitentwickelt, möchte ich einige seiner Ideen gerne vorstellen, so wie ich das in der Vergangenheit beim Thema CUT getan habe.
Hier sind drei Tipps wie man mit Aptitude und einem Linuxterminal sein System aufräumen kann. Wer gerne grafische Programme bevorzugt, wird all diese Optionen auch mit Synaptic finden können. Die Aptitude-Methode ist meiner Meinung nach aber universeller (und ressourcenschonender 😉 ). Im folgenden gebe ich die entsprechenden Aptitude-Befehle immer in Kurz- und Langschreibweise an. Ihr könnt den Suchbefehl search natürlich jederzeit durch purge ersetzen, um die Dateien endgültig zu entfernen.

1. Nicht benötigte Konfigurationsdateien endgültig löschen

Wenn man ein Paket mit aptitude remove oder sogar aptitude purge löscht, kann es vorkommen, dass einzelne Pakete dennoch Konfigurationsdateien zurücklassen. Oft ist das sogar ein erwünschter Zustand, da bei einer Neuinstallation eben die Konfiguration nicht neu erstellt werden muss, sondern direkt aus den zuvor zurückgebliebenen Dateien wiederhergestellt wird.

Suchen und Löschen

aptitude search ~c
aptitude search ?config-files

2. Entfernen von obsoleten Paketen

Debian läuft über Jahre stabil. Um diesen Qualitätszustand zu erreichen, durchläuft jedes Paket verschiedene Zweige innerhalb der Distribution von Experimental, Unstable über Testing bis Stable.
Es kann jedoch vorkommen, dass das Qualitätssicherungsteam das Entfernen eines Pakets beantragt, weil es entweder nicht mehr durch den ursprünglichen Upstream-Entwickler weiterentwickelt wird oder das Paket nicht mehr innerhalb von Debian betreut wird. Genauso gut kann ein Paket aus wichtigen Gründen umbenannt worden sein, weil der Paketbetreuer dem Benutzer zu einem Zeitpunkt mehrere Versionen anbieten wollte oder die alten Pakete in Übergangspakete für eine Veröffentlichung umbenannt wurden, aber in der darauf folgenden nicht mehr gebraucht werden.
Zurück bleiben irgendwann nur noch obsolete Pakete, die keine Sicherheitsaktualisierungen mehr erhalten und im schlimmsten Fall nutzlos auf der Festplatte verkümmern.

Suchen und Löschen

aptitude search ~o
aptitude search ?obsolete


Nicht immer möchte man alle als obsolet eingestuften Pakete löschen. Wenn man Pakete von Drittanbietern (wie z.B. Brother-Treiber) installiert hat, würden diese mit purge ebenfalls entfernt. Hier ist es deshalb besser mit

aptitude why "Paketname"


nachzuforschen, warum das Paket installiert wurde.

3. Pakete aus Drittquellen suchen und entfernen

Es gibt kaum einen Grund, warum man Drittquellen in Debian freischalten sollte. Hilfreich fand ich bisher aber immer deb-multimedia.org, wenn es z.B darum ging einen WebM-kompatiblen MPlayer für Debian Stable zu installieren. Natürlich nur, wenn es die neuere Version nicht schon in Debian-Backports gibt.
Bei Ubuntu hingegen erliegt man öfter der Versuchung mal das ein oder andere PPA freizuschalten und ja, manche sind auch wirklich nützlich. Möchte man herausfinden, welche Pakete auf dem eigenen System aus Drittquellen stammen, lässt sich das mit Aptitude so lösen:

Suchen und Löschen

aptitude search '~S ~i !~ODebian !~o'
aptitude search '?narrow(?installed, !?origin(Debian))!?obsolete'


Will man hingegen wissen, welche Pakete nicht aus dem Debian-Zweig stammen, den man gerade verwendet (in diesem Fall "Testing"), funktioniert dieser Befehl.

aptitude search '?narrow(?installed, !?archive(testing)?origin(Debian))'


Hierbei werden alle Pakete angezeigt, die nicht der Version entsprechen, die gerade in Testing verfügbar ist oder die aus anderen Zweigen wie Experimental oder Unstable stammen.

Posted on

Eine Beobachtung mit Debian Sid: Nvidia-Pakete auf hold setzen

Im Mai letzten Jahres habe ich ein Multiboot-System aufgesetzt und mir ein auf Spiele ausgerichtetes Debian Sid installiert. Es sind nur die notwendigen Programme für eine grafische Oberfläche mit Openbox installiert und ich bin sehr zufrieden mit dem Setup. Die Bedienung ist wie gewohnt reaktionsfreudig, einfach und schnell.
Das System ist dadurch immer topaktuell, insbesondere wenn es die Nvidia-Treiber betrifft, die für 3D-Spiele immer noch notwendig sind. Leider haben sie mir in der Vergangenheit auch Probleme bereitet. Ich habe deshalb vor mehreren Monaten beschlossen bei der letzten stabilen Version zu bleiben und die Pakete auf "hold" zu setzen und nicht mehr zu erneuern.
Das geht am einfachsten mit
aptitude hold '~nnvidia'
Mit ~n und dem folgenden Begriff werden alle Pakete, die "nvidia" im Namen führen bei einem Update zurückgehalten.
Mit dem Befehl
aptitude search '~ahold'
lassen sich alle geblockten Pakete anzeigen.
Nun, macht das wirklich Sinn? Ich denke ja. Voraussetzung ist, dass man gerne mit Unstable oder Testing arbeitet, ausprobiert und die neuste Software verwenden möchte. Updates für kritische Pakete, die in der Vergangenheit häufiger Probleme bereitet haben, sollen zurückgehalten werden. Im meinen Fall waren das die unfreien Nvidia-Treiber. Prinzipiell sollte sich das aber auch auf andere Software übertragen lassen.
Die Gefahr besteht natürlich, dass bei übertriebenem Einsatz von "hold" notwendige Updates verhindert werden, die z.B. sicherheitskritisch sind oder die Stabilität des Systems verbessern. Meine bisherige Erfahrung mit den Nvidia-Treibern hat mir aber gezeigt, dass es auch sehr sinnvoll sein kann Updates zu blockieren.
Für diesen Beitrag habe ich zuerst mit Partclone ein Backup der Partition gemacht, auf der das Spielesystem installiert ist. Die Vorgehensweise war die gleiche wie damals bei TinyCore Linux.

Sichern

partclone.extfs -c -d -s /dev/sda7 -o /home/apo/backup/20120422_loki_sda7.img

Wiederherstellen

partclone.restore -d -s /home/apo/backup/20120422_loki_sda7.img -o /dev/sda7
Wie sich mal wieder gezeigt hat, sind Backups einfach unheimlich nützlich. Nachdem ich mit
aptitude unhold '~nnvidia'
die Nvidia-Pakete freigegeben hatte, machte ich ein Update auf die aktuelle Version 290.40. Schon kurze Zeit später stellte ich fest, dass sich Spiele nicht mehr richtig beenden ließen, die grafische Oberfläche einfror und der Rechner nur noch mit Hilfe von SSH und der Konsole neugestartet werden konnte.
Ich bin daraufhin wieder zu Version 275 zurückgewechselt. Der Paketbetreuer für Nvidia kann in diesem Fall wenig machen. Diese Art von Regressionen treten häufig auf und können nur durch Nvidia selbst gelöst werden. Am besten man meldet das Problem im Support-Forum von Nvidia.
Meine Beobachtung ist, dass man bei Debian durchaus auch Pakete einmal auf Halt setzen kann, was der Stabilität keinen Abbruch tut. Eher im Gegenteil.

Posted on

Apt-Pinning für die Mutigen

Apt-Pinning. Ein oft genanntes Stichwort bei Debian und Co. Manchmal möchte man eine neuere Softwareversion installieren als diejenige, die in einer bestimmten Veröffentlichung von Debian- oder Ubuntu vorhanden ist. Die Gründe sind vielfältig. Vielleicht ist man lediglich an einem neuen Feature interessiert, andererseits kann man aber genauso gut auch auf ein neues Paket angewiesen sein oder es ausschließlich aus Neugier installieren.
Für Debian Stable gibt es genau aus diesem Grund das offizielle Backport-Projekt, mit dem sichergestellt ist, dass ausgewählte Pakete zwar aktueller sind als die bestehenden, aber immer noch stabil mit dem Gesamtsystem harmonieren.
Mit Apt-Pinning gibt es eine weitere Möglichkeit für erfahrene und fortgeschrittene Anwender aktuellere Software zu installieren. Insbesondere ist diese Methode für Debian Testing und Unstable interessant, wenn man z.B. Pakete aus dem Experimental Zweig zusätzlich installieren möchte und es kann unter Umständen auch für Debian Stable eine Option sein, wenn keine Backports vorhanden sind.
Meine Motivation für diesen Beitrag waren zwei Pakete in Debian Testing, die nicht aktualisiert wurden, obwohl in Unstable eine Version vorhanden war, die Bugs beseitigte.
Im Regelfall bin ich der typische, langweilige Debianbenutzer. Bei meinen Stable-Installationen läuft nur Stable, bei Testing nur Testing und bei Unstable...nur Unstable. Das ist zwar wenig aufregend, hat mich bisher aber immer vor instabilem Paket-Mischmasch bewahrt.
Manche ätzen, dass das Mischen von Paketen später nur mit der Suche nach Hilfe in irgendwelchen Foren oder IRC-Channels enden kann, wo die Methusalems dich erst einmal zu Abbitte und Buße auffordern. Du möchtest nicht wissen, was mit Leuten passiert, die eingestehen Ubuntu-PPAs mit Debianpaketen gemischt zu haben. Ihr seid also gewarnt! 😈
Apt-Pinning wird ausführlich und gut mit man apt_preferences erklärt. Hilfreich finde ich außerdem

Apt-Pinning anhand eines Beispiels

Bei meinem konkreten Problem ging es um Vim und Iceweasel. Vor einem Monat wurde ich durch Zufall auf #debian im IRC auf einen Bug in Vim aufmerksam gemacht, den ich zwei Stunden später dann per Reportbug gemeldet habe. Die Bearbeitung und Lösung des Problems war mustergültig. Der Paketverwalter bestätigte den Fehler und knapp zwei Wochen später war der Bug durch Upstream gefixt worden und das neue Paket in Debian Unstable. Doch auch Wochen danach kam davon nichts in Testing an. Mittlerweile hat es das Paket zwar nach Testing geschafft, doch gerade in so einem Fall kann Apt-Pinning weiterhelfen.
Mein anderer Favorit ist Iceweasel. In der Regel folge ich den Anweisungen auf mozilla.debian.net und habe zum gleichen Thema auch schon einen Beitrag geschrieben. Im Moment dauert es aber mal wieder mit dem Versionswechsel von 7 auf 8 und 9 ist nicht mehr weit entfernt.

Apt-Pinning Pin-Priorität

In einem solchen Fall ist Apt-Pinning sehr einfach global einzurichten. Standardmäßig wird jedem Paket, jeder Installation und Aktualisierung eine Priorität zugewiesen, von der man in der Regel gar nichts mitbekommt. Alle installierten Pakete haben Prioriät 100, alle anderen Pakete innerhalb einer Version wie z.B. Squeeze 500. Überprüfen lässt sich das mit

apt-cache policy

Die Zahlenwerte haben laut man apt_preferences eine unterschiedliche Gewichtung. Im Allgemeinen gilt umso höher der Zahlenwert, desto höher die Priorität ein Paket aus einer anderen Version zu installieren. Für mich funktioniert das Folgende ziemlich gut:
Erstellt euch in /etc/apt/apt.conf.d/ eine Datei mit beliebigem Namen. Ich habe hier 10default-release gewählt und editiert sie mit folgendem Inhalt. Z.B.:

APT::Default-Release "testing";

Das gilt natürlich nur für Debian Testing und sollte auf die entsprechende Debian Version geändert werden, die man gerade benutzt. Führt man danach ein aptitude update aus und anschließend apt-cache policy stellt man fest, dass sich die Priorität für die Pakete in Debian Testing auf 990 erhöht hat.
Zwar wäre das Folgende auch ohne diese Festlegung machbar gewesen, mir hilft es aber sicherzustellen, dass bei zukünftigen Updates immer Testing Pakete vor allen anderen bevorzugt werden.
Um nun Vim oder Iceweasel aus Debian Unstable zu installieren, muss man zuerst die Paketquellen in /etc/apt/sources.list aktualisieren und z.B. folgenden Eintrag für Unstable hinzufügen.

deb http://ftp.de.debian.org/debian unstable main

Danach lässt sich Iceweasel oder Vim aus Unstable mit

aptitude -t unstable install iceweasel vim

installieren. Bei zukünftigen Updates prüft Apt, ob die Version aus Unstable oder Testing neuer sein sollte. Da Testing bei mir eine höhere Priorität bekommen hat, wird im Zweifelsfall immer aus Testing installiert.
Das ist natürlich noch nicht alles. Apt kann mehr, viel mehr. Wenn ihr Ubuntu benutzt lässt sich z.B. explizit festlegen, ob ihr nur Pakete aus 10.04 bevorzugt oder doch besser 11.04. Wie wäre es, wenn man festlegen könnte, ob man nur bis Version X aus Debian Testing installiert und danach nur noch Pakete aus Experimental installiert? Wie schränke ich meine Prioritäten nur auf KDE-Pakete ein?
Apt ist ein wirklich sehr mächtiges und smartes Programm. Doch in der Regel kommt man wie oben beschrieben schon mit sehr wenig Aufwand aus und sollte beim Mischen von Paketen verschiedener Versionen immer skeptisch bleiben. Für alle, die sich eine maßgeschneiderte Preferences-Datei anlegen möchten, empfehle ich wie schon gesagt einen Blick in man apt_preferences zu werfen oder sich das folgende fortgeschrittene Beispiel anzuschauen.
Raphael Hertzog bezeichnete vor sieben Monaten die Installation von Gnome 3 aus Debian Experimental in Testing als "apt-pinning for the brave". Das zu bewerten, liegt wie immer bei euch. 😉

Posted on

apt-listbugs: Mehr Schutz vor schweren Bugs

Ich bin erst vor ca. 3 Monaten auf apt-listbugs aufmerksam geworden, obwohl ich seit längerer Zeit auf verschiedenen Rechnern Debian Unstable benutze. Mir war nicht sofort klar, wie das Programm funktionieren würde und ob ich es explizit aufrufen musste, um potentiell fehlerhafte Pakete zu finden.
Tatsächlich ist es äußerst einfach damit umzugehen. Man installiert es und fertig.
Jedesmal wenn ich ein Update mit Debian mache, überprüft apt-listbugs automatisch, ob im Bug Tracking System bei Debian ein schwerwiegender Fehler zu einem Paket gemeldet worden ist. Falls dies der Fall ist, gibt es eine Warnmeldung und die Abfrage, ob man das neue Paket wirklich installieren möchte.
Bisher hatte ich zwei Erfahrungen gemacht. Entweder der gemeldete Fehler war nicht von so schwerwiegender Natur und ich konnte ihn ignorieren oder aber apt-listbugs konnte mir den Fehler nicht melden, weil er nicht im neuen Paket auftrat, sondern sich in einem schon installierten befand, aber erst wirksam wurde nachdem ich die neue Software installiert hatte.
Der letzte Fall war auch das Problem bei dem weitläufigen Nvidia Bug und Xorg 1.11, der nicht nur mich, sondern eine Reihe anderer Leute auch betraf. Leider wurde die angestoßene Diskussion auf debian-devel nicht fortgeführt. Hier gäbe es sicher noch Verbesserungspotential.
Also alles Mist? Überhaupt nicht. Vor wenigen Tagen rettete mich apt-listbugs vor der Installation von Chromium 15. Das Paket war komplett unbrauchbar, so dass Chromium rein gar keine Webseite mehr darstellen wollte. In diesem Fall entschied ich mich bei meinem alten Chromium 14 zu bleiben und besser auf die Fehlerbehebung zu warten.
Wer also viel mit Debian Sid oder sogar Experimental zu tun hat, dem kann ich apt-listbugs auf jeden Fall empfehlen. Es ist zwar nicht perfekt, aber es schützt einem mit Sicherheit vor der ein oder anderen brenzligen Situation.

Posted on

Einfache Suchmuster mit Aptitude

Mich beschäftigte vor ein paar Tagen die Frage, welche und wie viele unfreie Pakete auf meinem Inspiron 4000 mit Debian und Openbox installiert sind und welche Möglichkeiten es gibt dies schnell herauszufinden.
Unter Gnome erledigt Synaptic meist den Job, wenn es eine grafische Oberfläche mit Suchfeld und Eingabemaske sein soll. Ubuntus neues Software Center bietet eine ähnliche, stärker visuell ausgerichtete, aber grobere Funktionalität.
Da es ein leichtgewichtiges System bleiben sollte, kamen sowohl Synaptic als auch das Software Center nicht in Frage.
Dann kommt aptitude ins Spiel, ein Frontend für Debians und Ubuntus Paketverwaltungssystem. Seit ich mit Debian angefangen habe, ist es für mich der bequemste Weg um schnell ein Paket zu installieren oder wieder zu entfernen.
Aptitude bietet aber noch zahlreiche andere Optionen, um mehr über Programme herauszufinden. Eines seiner Stärken ist die Option search.

aptitude search '(?section(contrib) ?installed)'

Bei Suchmuster mit search gibt es eine Lang- und eine Kurzform. Attribute für Suchmuster beginnen bei der Langform mit einem ? und dem Attribut. Der Suchbegriff folgt meist in Klammern danach.
Die Kurzform beginnt mit dem Tilde Symbol "~". Der Suchbegriff wird direkt an das Attribut angehängt.

aptitude search '(~scontrib ~i)'
oder
aptitude search '(~snon-free ~i)'

Die Suche im Bereich contrib und non-free und nach nur installierten Paketen ergab.

i A b43-fwcutter - Werkzeug zum Entnehmen der Broadcom 43xx Firmware
i firmware-b43-installer - Installer package for firmware for the b43 driver
i vice - The Versatile Commodore Emulator
i dropbox - secure backup, sync and sharing util
i firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel

Die b43 Pakete sind zwar freie Software, laden aber die unfreie Firmware für meine Linksys-WLAN-Karte herunter.
Dropbox ist als Backup- und Austauschwerkzeug von Dateien mit Mac- oder Windowsnutzern sehr nützlich und ohne firmware-linux-nonfree würde weder meine Maestro-Soundkarte noch das LAN-Kernel-Modul e100 funktionieren.
Der Rest ist Freie Software. 🙂
Wer wissen will, welche freien Spiele mit Debian angeboten werden, kann dies mit einer Suche im Bereich "games" herausfinden und die Suche mit bestimmten Begriffen auch auf die Paketbeschreibung erweitern. Das ! negiert wie in Programmiersprachen gewohnt das Attribut.

aptitude search '(~sgames !~i)'
aptitude search '(~sgames !~i ~dHammer)'

Mit search gibt es noch viel mehr Möglichkeiten, darunter z.B. auch die Suche nach bestimmten Paketverwaltern und Paketversionen.
Ein guter Einstieg zu den verschiedenen Optionen von Aptitude ist der Aptitude Reference Guide.