#debian.de - Frequently Asked Questions
   
       

 
 

#debian.de

 Am Anfang...
 Weisheiten
 Stats
 Karte
 Keyanalyse
 Altersheim
 (No)Paste
 Wiki

Fragen?

 Netiquette
 FAQ
 Smart Questions
 Links/Bücher

Debian

 Debian-Homepage
 Maintenance HOWTO

Verschiedenes

 VCS & Zuständigkeit
 Danksagung
 Copyright
 Feedback

 
 


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ weiter ]


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


2.1 Welche Vorteile bietet aptitude gegenüber apt-get?

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. Allerdings speichert aptitude die Informationen, die es für den größeren Funktionsumfang braucht, in einer eigenen Datei, die von apt nicht genutzt wird - d.h. um in den vollen Umfang der Vorteile zu kommen, sollte man nicht zwischen den verschiedenen Frontends wechseln, sondern sich für eines entscheiden und dann auch dabei bleiben. 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 fast 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 kann von einem regulärem User benutzt werden

Es mag unbekannt sein, aber aptitude lässt sich von einem normalen User im GUI-Modus 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, indem man aptitude beendet. (Es ist auch möglich, vorherige Veränderungen durch drücken von Strg+u rückgängig zu machen.)


2.1.3 aptitude hat eine leistungsfähige Benutzeroberfläche

Die grafische 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.4 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.5 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. Mittlerweile bietet dpkg selbst auch ein eigenes Logging.


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. Umgekehrt listet dpkg -Lfoobar auf, welche Dateien zu einem installierten Paket gehören.

  • 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. etch (4.0), lenny 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, amd64, 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.

  • 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äßigen 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 Linux-Image von Debian installiert (linux-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 Linux-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 folgendermaßen 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

         apt-get 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 "apt-get 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 (oder in zB /etc/apt/sources.list.d/sid.list) einzutragen, ohne dass er gleich die komplette Distribution updatet, man aber trotzdem komfortabel Pakete für Sid installieren kann.

Für stable empfiehlt es sich erst einmal zu prüfen, ob das gewünschte Paket nicht vielleicht bereits auf backports.debian.org gepflegt wird.

Um dennoch Pakete aus Unstable zu verwenden geht man wie folgt vor:

Dazu schreibt man die Zeile

     APT::Default-Release "6.0*";

für Squeeze oder

     APT::Default-Release "wheezy";

für Wheezy 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, außer 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. linux-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, das 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/linux-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 (etch, lenny, sid, kde, java, ATI-Treiber, ...)

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 in die sources.list, 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 Lenny == "oldstable", Debian 5.0 (Veraltet, nur für bestehende Installationen nutzen)

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

2.13.2 für Squeeze == "stable", Debian 6.0

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

2.13.3 für Wheezy == "testing"

         deb     http://ftp.de.debian.org/debian wheezy main
         deb-src http://ftp.de.debian.org/debian wheezy main
     
         deb     http://security.debian.org/ wheezy/updates main
         deb-src http://security.debian.org/ wheezy/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/ testing/updates main
         deb-src http://security.debian.org/ testing/updates main

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


2.13.5.1 Google Chrome

Diese werden am besten in einer eigenen sources.list im Verzeichnis /etc/apt/sources.list.d/ verwaltet.

         cat /etc/apt/sources.list.d/google-chrome.list
         $ deb http://dl.google.com/linux/chrome/deb/ stable main

Weitere, inoffizielle sources.list Einträge


2.14 Von Lenny auf Squeeze aktualisieren

Da Squeeze nach langer Wartezeit den "stable"-Status erreicht hat und Lenny über kurz oder lang archiviert werden wird, sollte man bei Gelegenheit auf Squeeze umsteigen (es sei denn man ignoriert die potenzielle Gefahr aus dieser Problematik). Zunächst liest man sich dazu die Release Notes durch (oder überfliegt zumindest die wichtigsten Kapitel. Die Kurzversion für Ungeduldige lautet: Man ändert die sources.list entsprechend 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 vertrauenswürdigen Paketquellen

Seit Etch ist eine neue Version von apt enthalten, die die Paketinstallation etwas besser absichert. Dafür wird eine gpg-Signatur (eine digitale Unterschrift) überprüft. Dazu muss gpg aber wissen, welchen Schlüsseln 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 Schlüssel des Debian-Projekts für das Jahr 2006 und das Etch-Release importiert. Mit diesem Kommando verschwindet schon einmal ein Teil der komischen Fehlermeldungen. Sollte weiterhin von "untrusted sources" und ähnlichem die Rede sein, so liegt dies wohl daran, dass man zusätzliche Quellen für 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 Schlüssel wirklich vertrauen wollen, so lässt 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 Schlüssel-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. Nähere 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.org/


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ weiter ]


#debian.de - Frequently Asked Questions

#debian.de-FAQ-Team


 
   
  Last modified: Fri Oct 22 13:56:37 2010 - Last compiled: Thu Mar 28 17:00:05 2024