#debian.de - Frequently Asked Questions
Kapitel 2 - Paketsystem, Paketmanagement, Installation

2.1 Warum ist aptitude besser als apt-get und dselect?

Aptitude ist nicht nur ein weiteres Frontend für apt und dpkg, wie es apt-get und dselect es sind. Es wurde zwar ursprünglich als direkter Nachfolger zu dselect entwickelt, besitzt mittlerweile aber einen größeren Funktionsumfang als dieses. Die vollständige Dokumentation zu aptitude findet sich hier: http://people.debian.org/~dburrows/aptitude-doc/en/

Aber warum denn nun aptitude?

2.1.1 aptitude kann sich so wie apt-get verhalten

Die Befehle aptitude update, aptitude upgrade und aptitude install sehen so aus und verhalten sich genauso wie apt-get. Zusätzlich gibt es noch einige Funktionen, die dabei helfen die Übersicht über Abhängigkeiten und unnötige Pakete zu behalten.

2.1.2 aptitude behält die Übersicht über installierte Pakete

Genervt davon mit debfoster und deborphan immer wieder das System zu säubern? Aptitude nimmt Ihnen diese Arbeit ab. Wenn Sie alle Pakete mittels aptitude installieren, behält es die Übersicht über Pakete, die als Abhängigkeit mitinstalliert wurden und entfernt diese, wenn sie nicht mehr gebraucht werden.

2.1.3 aptitude verwaltet Paket-Empfehlungen

Erst neuere Versionen von apt-get zeigen überhaupt an, welche zusätzlichen Pakete zu einem Programm empfohlen werden. Davor war es nur mit einigem Aufwand möglich herauszufinden, welche Software das eigentliche Programm noch erweitern und teilweise wichtige Funktionen liefern.

Aptitude verwaltet diese Paket-Empfehlungen nun standardmässig, sogar im Command-Line-Modus.

2.1.4 aptitude kann von einem regulärem User benutzt werden

Es mag unbekannt sein, aber aptitude lässt sich von einem normalen User im GUI-Modues bedienen. Da es als normaler User läuft, ist es unmöglich das System zu zerstören. Erst wenn aptitude gesagt bekommt, dass es die Änderungen ausführen soll, erscheint ein Dialog der zur Eingabe des root-Passworts auffordert. Bis zu diesem Punkt sind alle Änderungen nicht wirksam und man kann diese immer zurücksetzen, in dem man aptitude beendet. (Es ist auch möglich vorherige Veränderungen durch drücken von Strg+u rückgängig zu machen.)

2.1.5 aptitude hat eine leistungsfähige Benutzeroberfläche

Die grafischen Oberfläche von aptitude erlaubt eine einfache Verwaltung der installierten Pakete. Auch hilft aptitude, durch die Einordnung aller Programme in Kategorien, leichter interessante und nützliche Programme zu finden. Die Suchmaske erlaubt es direkt nach Name, Beschreibung, Maintainer, Abhängigkeiten, usw. zu suchen.

2.1.6 aptitude listet veraltete Pakete auf

Es kommt immer wieder vor, dass ein Paket aus Debian entfernt und somit nicht weiter unterstützt wird. Apt belässt solche Pakete auf Ihrem System, ohne Sie darauf hinzuweisen. Aptitude hingegen listet diese Pakete im Bereich "Veraltete und selbst erstellte Pakete" auf und hilft Ihnen so beim Aufspüren dieser.

2.1.7 aptitude kommt mit verschiedenen Quellen klar

Es dürfte bekannt sein, dass es möglich ist, viele Einträge in der Datei /etc/apt/sources.list zu haben. Somit kann es sein, dass mehrere Versionen eines Programms auf verschiedenen Servern existieren. Aptitude erleichtert es eine Version zu installieren, die nicht dem Standard entspricht. Und sollte einmal unstable ein Paket aus unstable nicht installierbar sein, vereinfacht aptitude es die Version des Paket aus dem testing-Zweig zu installieren.

2.1.8 aptitude erstellt Log-Dateien über alle seine Aktivitäten

Aptitude erstellt Logs in /var/log/aptitude über die Installation bzw. Entfernung von Paketen, sowie über Upgrades. Das macht es einfach herauszufinden, was schief gelaufen ist, sollte das System nachher nicht mehr richtig funktionieren.

2.2 In welchem Paket ist die Datei foobar?

• Wenn man den exakten Dateinamen hat, findet man es am einfachsten mit apt-file (aus dem gleichnamigen Paket). Einmal apt-file update aufrufen, um die Dateilisten zu installieren, danach kann man mit apt-file search DATEI suchen.

• Auch mit dpkg -Sfoobar bekommt man heraus zu welchem installierten Paket eine Datei gehört, sofern das betreffende Paket installiert ist.

• Die manuelle Variante von apt-file für solche, die es sich nicht installieren wollen oder können, ist das manuelle (zgrep) Durchsuchen der Contents-Dateien: Sucht man eine Datei, die noch nicht installiert ist, holt man sich am besten die Datei debian/dists/$(DIST)/Contents-$(ARCH).gz vom nächsten Debian-Mirror und zgrept nach dem Dateinamen.

             $ zgrep foobar Contents-$(ARCH).gz
  

  $(DIST) steht hierbei für den Codenamen der Debian-Version (z.B. woody (3.0), sarge (3.1), etch oder sid). Alternativ kann man auch den momentanen Zustand der gewünschten Version nehmen (stable, testing oder unstable). $(ARCH) steht für die Architektur (i386, powerpc, etc.).

• Sucht man ein Paket und nicht eine konkrete Datei kann man z.B. mit apt-cache search foobar die Beschreibung durchsuchen und erhält eine Liste aller Pakete in denen foobar vorkommt.

• Man kann sich auch das Paket grep-dctrl installieren (aptitude install grep-dctrl). Danach stehen grep-status und grep-available zur Verfügung mit denen man die Beschreibungen der installierten (grep-status) und der verfügbaren Pakete (grep-available) durchsuchen kann.

• Das Ganze gibts noch etwas ausführlicher, dafür aber auf Englisch, unter http://olug.cs.oberlin.edu/~kturner/deb-where.html.

• Man kann aber auch das Paket auto-apt installieren (aptitude install auto-apt) und dann mit auto-apt search foobar nach den Paketen suchen, die die Datei foobar enthalten. Man sollte aber die dazugehörige Datenbank vor dem ersten Aufruf anlegen und in regelmässigen Abständen aktualisieren (auto-apt update). Im Prinzip werden damit die Content-Dateien automatisch heruntergeladen und nach der Zeichenkette foobar durchsucht, was den meisten notorisch faulen Benutzern unter uns einiges an Handarbeit abnehmen sollte.

• Eine weitere Möglichkeit besteht in der Verwendung von findpkg von Joey, das im Prinzip nur ein Wrapper für grep ist und eine interne Datenbank verwendet, die regelmäßig mit findpkg -u aktualisiert werden muss. Öfter als wöchentlich ist nicht nötig, da das Original auch nicht häufiger aktualisiert wird.

• Eine weitere bequeme Variante zum Suchen von Programmen findet sich unter http://packages.debian.org. Dort ist es nicht notwendig, sich die Contents-$(ARCH).gz herunterzuladen.

2.2.1 Aber in welchem Paket ist die Datei -ldb, -lperl oder -ljpeg, o.ä.?

Das sieht nach der typischen Fehlermeldung des Compilers aus, etwas in der Art von:

         /usr/bin/ld: cannot find -lgnomevfs
         collect2: ld returned 1 exit status
         make[3]: *** [galeon-bin] Fehler 1
         make[3]: Leaving directory `/tst/debian_tmp/galeon-0.12.1/src'

Die gesuchte Datei heißt nicht -lgnomevfs (-l... ist eine Abkürzung des Linkers), sondern libgnomevfs.a.

2.2.2 Der Kernel sucht aber nach etwas mit Ncurses, wo finde ich das?

Siehe Kernel selbst kompilieren - nach Debian-Art, Abschnitt 2.11.

2.3 Kernel-Panik: "unable to mount rootfs" mit dem Debian-Kernel.

F: Ich habe ein Kernel-Image von Debian installiert (kernel-image-foo-bar), beim Booten kriege ich nur Kernel-Panik: "unable to mount rootfs".

A: Selbst schuld. Das Kernel-Setup schreibt klar und deutlich, was man in /etc/lilo.conf (bzw. die Konfigurationsdatei deines Boot-Loaders) eintragen soll und fragt DICH, ob DU es getan hast. Wer nicht liest, muss leiden.

Abhilfe: Das System mit dem alten Kernel booten (sofern der im Lilo-Menü noch vorhanden ist) oder mit der Installationsdiskette/CD durch Angabe von "rescue root=/dev/meine_partition". Dann /etc/lilo.conf editieren, in die ersten Zeilen "initrd=/initrd.img" eintragen, "lilo" aufrufen und neu booten.

2.4 Kernel-Panik: "unable to mount rootfs" mit einem selbst kompilierten Kernel.

F: Ich habe mir ein eigenes Kernel-Image erstellt, beim Booten kriege ich nur Kernel-Panik: "unable to mount rootfs".

A: Selbst schuld. Entweder hast du den Treiber für dein Festplatten-Subsystem vergessen einzubauen, oder der Treiber konnte nicht geladen werden (z.B. wenn der Treiber modular gewählt wurde, aber keine initrd erstellt oder in der Bootloader-Konfiguration nicht angegeben wurde).

2.5 dpkg -l zeigt die Spalten nur abgeschnitten an

         bash$ COLUMNS=200 dpkg -l | less

Damit wird dpkg eine Terminalbreite von 200 Zeichen vorgegeben, und dementsprechend breit stellt dpkg die Spalten dar.

2.6 Wie setze ich noch mal ein Paket auf hold?

Da aptitude-holds durch apt und dselect ignoriert werden und umgekehrt apt- bzw. dselect-holds durch aptitude ignoriert werden (siehe Bug #137771), muss man Pakete mit dem Paketverwaltungsprogramm, das man benutzt auf hold setzen.

Bei apt bzw. dselect ist es eigentlich ganz einfach:

         $ echo paket hold | dpkg --set-selections

wobei paket mit dem Namen des gewünschten Pakets zu ersetzen ist. Wenn man mehrere Pakete auf einmal auf hold setzen will, kann man sich mit einem here-Dokument behelfen:

         $ dpkg --set-selections << EOF
         paket1 hold
         paket2 hold
         paket3 hold
         EOF

Falls aptitude verwendet wird, ist folgendermassen vorzugehen:

         $ aptitude hold paket1 paket2 ...

oder aptitude starten, das Paket suchen und mit der =-Taste auf hold setzen.

Auch auf hold gesetzte Pakete lassen sich per

         aptitude install paket

explizit installieren, nur bei einem upgrade werden sie nicht aktualisiert. Bei diesem Befehl bleibt das Paket auf hold. Der entsprechende Befehl für aptitude

         aptitude install paket

entfernt den Status hold.

2.7 Wie werde ich ein Paket mit seinen Abhängigkeiten wieder los?

Wenn auch die automatisch mitinstallierten Abhängigkeiten oder alle nicht mehr benötigten Bibliotheken entfernt werden sollen, empfiehlt sich der Einsatz von debfoster. Es schaut sich die "obersten" Pakete im Abhängigkeitsbaum an und fragt jeweils, ob es diese entfernen soll. So kann man z.B. nach "aptitude install gnome" wieder alle Gnome-Pakete loswerden. Wer aptitude benutzt, hat dort eine bereits ähnliche Funktion.

2.8 Sid Pakete auch in "testing"/"stable" bequem installieren

Seit Woody hat apt die sehr bequeme Funktionalität, eine Default-Distribution anzugeben, die er bei Installationen von neuen Paketen bevorzugt. Das macht es möglich, auch die Zeilen für Sid in die sources.list einzutragen, ohne dass er gleich die komplette Distribution updatet, man aber trotzdem komfortabel Pakete für Sid installieren kann.

Dazu schreibt man die Zeile

     APT::Default-Release "3.1*";

für Sarge oder

     APT::Default-Release "testing";

für Etch entweder in die Datei /etc/apt/apt.conf oder in eine neue Datei unter /etc/apt/apt.conf.d. Überprüfen lässt sich die Einstellung per apt-cache policy.

Danach kann man beruhigt die Zeilen für Sid in die sources.list eintragen, sie werden aber beim aptitude upgrade nicht beachtet, ausser man gibt dies explizit per aptitude upgrade -t unstable an.

Wenn man jetzt ein Paket aus Sid installieren will, benutzt man folgende Zeile:

     aptitude install paket/unstable

Dabei werden fehlende Abhängigkeiten auf Pakete in Sid nicht automatisch aufgelöst, die sollte man gegebenenfalls dann noch per Hand zum Installationsaufruf hinzufügen.

Möchten Sie es sich einfacher machen (*) und apt erlauben, automatisch die Abhängigkeiten auf "unstable"-Pakete zu verfolgen, geht das mit einem anderen Aufruf:

     aptitude -t unstable install paket

(*) VORSICHT: Das kann zu unerwarteten Problemen und langen Installationsorgien führen.

PS: Ein noch feinerer Mechanismus ist das sog. Apt-Pinning, das in der Manpage apt_preferences (5) dokumentiert ist.

2.9 Apt über einen HTTP-Proxy benutzen

         <case> wie geb ich einen http proxy in der bash an ? HTTP_PROXY ? dann tut das gerade bei mir nicht..
         <Joey> http_proxy
         <Zomb> case / Joey: ich zitiere euch mal im FAQ.
         <case> zomb: aber dann vervollständige es: export http_proxy="service://domain_or_ip:port"

Und da wären wir. Die *_proxy-Variablen werden auch von einigen anderen Programmen benutzt, z.B. von w3m. Die Datei /etc/environment wird beim Login eingelesen (von PAM), also trägt man da so etwas ein:

         http_proxy=http://www-proxy.t-online.de:80
         ftp_proxy=http://ftp-proxy.t-online.de:80
         no_proxy=localhost

Vor der Benutzung einfach erneut einloggen oder die Variablen mit source /etc/environment ; export http_proxy ftp_proxy no_proxy in die aktuelle Shell einlesen.

Alternativ dazu kann man auch apt direkt so konfigurieren, dass es einen Proxy verwendet, dazu müssen in /etc/apt/apt.conf oder in eine Datei in /etc/apt/apt.conf.d/ (/etc/apt/apt.conf.d/custom bietet sich beispielsweise an) folgende Zeilen eingefügt werden:

         Acquire::http::Proxy "http://proxy.adresse.de:port";
         Acquire::ftp::Proxy "http://proxy.adresse.de:port";

2.10 Kernel-Module bauen für Debian-Kernel

         /* Vorgeplänkel:
         > Ich habe Kernel-Module für meine Karte kompiliert
         > Es wollte /usr/src/linux haben
         > Ich habe Kernel-Quellen von kernel.org installiert
         > Aber es sagt, ich habe die falsche Version
         > Dann habe ich die Version per Hand in den Headern geändert
         > Aber jetzt zeigen die Module "unresolved symbols" und ähnlichen Mist
         */

Die Abhängigkeit von dem lokalen /usr/src/linux-Verzeichnis hat seinen Sinn. Dort werden die Header des LAUFENDEN Kernels erwartet, und diese sollten GENAU passen. Quellen eines anderen Kernels bringen nur Ärger.

Für vorkompilierte Debian-Kernel werden auch sog. kernel-headers-Pakete ausgeliefert. Mit diesen kann man Module nachträglich bauen, ohne den ganzen Quellbaum zu besitzen. Diese installiert man so:

       module-assistant prepare
       (aptitude install module-assistant wenn nicht vorhanden)

2.11 Kernel selbst kompilieren - nach Debian-Art

Debian hat ein kleines Programm, dass den Kernel kompiliert (ggf. inklusive von Zusätzen wie ALSA oder dem Nvidia-Treiber) und daraus Debian-Pakete erstellt, die dann einfach installiert - und wieder deinstalliert - werden können.

Folgendes Kommando installiert das Paket und wichtige Zusatzpakete:

         $ aptitude install kernel-package fakeroot libc6-dev gcc debianutils make libncurses5-dev

Jetzt entpackt man einen Kernel z.B. nach /usr/src/kernel-source-VERSION, wechselt in dieses Verzeichnis, konfiguriert den Kernel wie gewohnt mit make menuconfig, make xconfig oder make config, und startet dann mit

         $ make-kpkg kernel_image --rootcmd fakeroot --revision meinkernel.01

den Kompiliervorgang.

Wenn der abgeschlossen ist, kann man als root mit

         # dpkg -i /usr/src/kernel-image-VERSION_meinkernel.01_i386.deb

den Kernel wie gewohnt installieren.

Zusatz-Module wie ALSA, LM-Sensors, Nvidia lassen sich mit module-assistant nachinstallieren.

         $ m-a list nvidia
         $ m-a a-i nvidia

Tipps: in /boot/config.VERSION liegt die Konfiguration des installierten Kernels. Wird diese nach /usr/src/kernel-source-VERSION/.config kopiert, braucht man mit make oldconfig nur noch die neu hinzugekommenen Optionen auswählen.

Bei Bedarf baut m-a fakesource den ursprünglichen Kernel-Quellcode nach (mehr oder weniger).

2.12 Debian-Pakete aus dem Quellcode bauen

Es gibt im Prinzip drei Arten von Quellcode:

• 1. Quellcode aus dem Debian-Archiv. Diesen kann man automatisch mit "apt-get source ..." herunterladen, wenn man die passenden deb-src-Zeilen in sources.list stehen hat.

• 2. Fremder Quellcode mit einem debian/-Verzeichnis drin.

• 3. Wald-und-Wiesen-Quellcode-Paket zum selbst kompilieren.

Wie baut man nur Pakete? Zunächst ein paar Vorbereitungen:

         (als root) #  aptitude install build-essential fakeroot

• Bei der Version 1:

             (als root) # apt-get build-dep PAKET
             (als user) $ fakeroot apt-get -b source PAKET
  

  Herauskommen sollte(n) fertige Debian-Pakete. Manchmal verzettelt sich apt-get beim build-dep Schritt, dann kann man einfach weitermachen und warten, bis fehlende Abhängigkeiten gemeldet werden, z.B. so:

             dpkg-checkbuilddeps: Unmet build dependencies: liblircclient-dev
  

  Die aufgelisteten Pakete muss man dann händisch nachinstallieren und den Build-Vorgang wiederholen.

• Version 2: Ähnlich vorgehen wie bei Version 1, nur kann apt-get damit nicht funktionieren. Man startet den Build also manuell, nachdem man die Source-Dateien heruntergeladen hat (paket_xyz.dsc, paket_xyz.tar.gz oder .orig.gz plus .diff.gz).

             dpkg-source -x paket*.dsc
             cd paket*
             dpkg-buildpackage -us -uc -rfakeroot
  

• Version 3: Bei Third-Party-Code kann man alles mögliche vorfinden. Oft trifft man mit autoconf erstellte Projekte (configure-Skript), diese erleichtern die Arbeit (manchmal). Um solche Programme sauber zu installieren, kann das Tool checkinstall (gleichnamiges Paket) verwendet werden, das die Installation überwacht und deinstallierbare Pakete erzeugen kann. Bei Build-Abhängigkeiten in fremden Paketen muss man sich oft auf die Angaben des Autors verlassen (siehe Dateien README oder INSTALL), die Namen der nötigen Debian-Pakete kriegt man wie oben (In welchem Paket ist die Datei foobar?, Abschnitt 2.2) beschrieben raus.

2.13 sources.lists (sarge, etch, sid, kde, java, ATI-Treiber, ...)

Wer sich weigert, seine apt sources.list ganz komfortabel mit apt-setup (im Paket base-config) zusammenzustellen, findet hier möglicherweise was er braucht.

Eigentlich gehören noch Einträge wie contrib oder non-free hinein, wie z.B. deb http://ftp.de.debian.org/debian stable main contrib non-free, aber in diesen Komponenten befinden sich keine eigentlichen Debian-Pakete (die gibt es nur in "main") und können nicht hundertprozentig von uns supportet werden, also beschränken wir uns hier auf die Angabe der Quellen der main-Pakete. Der Vorgang ist denkbar einfach:

• /etc/apt/sources.list editieren und die gewünschten Source-Zeilen aus den unten aufgelisteten Serien dort eintragen

• Paket-Indizes holen mit:

       aptitude update
  

• Upgrade durchführen:

       aptitude dist-upgrade
  

2.13.1 für Woody == Debian 3.0 (Veraltet, nur für bestehende Installationen nutzen)

         deb     http://ftp.de.debian.org/debian woody main
         deb-src http://ftp.de.debian.org/debian woody main
         deb     http://ftp.de.debian.org/debian-non-US woody/non-US main
         deb-src http://ftp.de.debian.org/debian-non-US woody/non-US main
     
         deb     http://security.debian.org/ woody/updates main
         deb-src http://security.debian.org/ woody/updates main

2.13.2 für Sarge == "stable", Debian 3.1

         deb     http://ftp.de.debian.org/debian sarge main
         deb-src http://ftp.de.debian.org/debian sarge main
     
         deb     http://security.debian.org/ sarge/updates main
         deb-src http://security.debian.org/ sarge/updates main

2.13.3 für Etch == "testing"

         deb	http://ftp.de.debian.org/debian etch main
         deb-src	http://ftp.de.debian.org/debian etch main
     
         deb	http://security.debian.org/ etch/updates main
         deb-src	http://security.debian.org/ etch/updates main

2.13.4 für Sid == "unstable"

         deb     http://ftp.de.debian.org/debian sid main
         deb-src http://ftp.de.debian.org/debian sid main
     
         deb     http://security.debian.org/ etch/updates main
         deb-src http://security.debian.org/ etch/updates main

2.13.5 Inoffizielle apt sources - nicht von, aber für Debian

2.13.5.1 Blackdown Java JDK 1.3

         deb ftp://ftp.mirror.ac.uk/sites/ftp.blackdown.org/java-linux/debian woody main non-free

Liste der Mirror-Server.

2.13.5.2 OpenOffice.org

         deb     http://ftp.freenet.de/pub/debian-openoffice woody-test main contrib
         deb-src http://ftp.freenet.de/pub/debian-openoffice woody-test main contrib

Bitte beachten: Alles andere ist völlig überholt und unaktuell; aus dem einfachen Grund, dass dieses Repository nicht mehr aktualisiert wird weil OpenOffice.org schon seit geraumer Zeit in sid bzw. sarge ist und dem entsprechend die Entwicklung und Aktualisierungen dort stattfinden.

Weitere, inoffizielle sources.list Einträge

2.14 Von Woody auf Sarge aktualisieren

Da Sarge nach langer Wartezeit den "stable"-Status erreicht hat und Woody wahrscheinlich nicht ewig mit Security-Updates unterstützt wird, sollte man früher oder später auf Sarge umsteigen (es sei denn man ignoriert die potenzielle Gefahr aus dieser Problematik). Zunaechst liest man sich dazu die Release Notes durch (oder ueberfliegt zumindest die wichtigesten Kapitel. Die Kurzversion fuer Ungeduldige lautet: Man aendert die sources.list ensprechend der Vorlage und macht ein aptitude update && aptitude dist-upgrade. Wichtig ist, dass man alle Meldungen aufmerksam mitliest. Speziell bei Serverdiensten sollte man am Schluss die Konfigurationsdateien sehr sorgfältig durchsehen - hat ein Paket nicht mehr denselben Syntax, muss man es von Hand anpassen.

2.15 apt-get/aptitude meckert wegen irgendwelchen Keys / nicht vertrauenswuerdigen Paketquellen

Unter Etch, dem derzeitigen "testing", ist eine neue Version von apt-Enthalten, die die Paketinstallation etwas besser absichert. Dazu wird eine gpg-Signatur (eine digitale Unterschrift) ueberprueft. Dazu muss gpg aber wissen, welchen Schluesseln man selbst vertraut. Zur Verwaltung dient das Tool apt-key. Ein apt-key list zeigt Beispielsweise alle Keys an, denen man vertraut, dabei werden automatisch die notwendigen Schluessel des Debian-Projekts fuer die Jahre 2004 und 2005 importiert. Mit diesem Kommando verschwindet schon einmal ein Teil der komischen Fehlermeldungen. Sollte weiterhin von "untrusted sources" und aehnlichem die Rede sein, so liegt dies wohl daran, dass man zusaetzliche Quellen fuer apt in seiner sources.list eingetragen hat. Dies sieht dann in etwa so aus: W: GPG error: ftp://ftp.gwdg.de testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BB5E459A529B8BDA Sollte man dem genannten Schluessel wirklich vertrauen wollen, so laesst er sich mit:

       keyid=lange_keyid_die_apt_anmeckert ; 
       gpg --keyserver subkeys.pgp.net --recv-key $keyid ; 
       gpg --fingerprint $keyid ;
       <kontrollieren des ausgegebenen Fingerprints>
       gpg --armor --export $keyid | apt-key add -

in den Schluessel-Ring von apt importieren. Wichtig ist hier vor allem das Kontrollieren des Fingerprints. Kontrolliert man nicht anhand des Fingerprints, dass Signaturen tatsächlich vom Anbieter der Pakete stammen, ist ganze System ausgehebelt und bringt keinen Mehrwert an Sicherheit. Naehere Informationen dazu finden sie in man apt-key und man apt-secure.

2.16 Ich mag "testing" nicht, kann ich wieder zurück?

Die kurze Antwort ist: Nein, mach es lieber nicht. Es gibt dabei zahlreiche Probleme und Du bist auf Dich alleine gestellt, weil dieser Schritt nicht unterstützt wird. Es wird zumeist einfacher sein, die alte Version von Grund auf neu zu installieren.

Falls Du diesen Schritt aber trotzdem unbedingt versuchen willst, hat Joey dies in einem Artikel über Apt-Pinning beschrieben, der auch Online verfügbar ist: http://www.linux-magazin.de/Artikel/ausgabe/2002/11/apt/apt.html

2.17 Wo finde ich alte Debian-Pakete?

http://snapshot.debian.net/

#debian.de - Frequently Asked Questions