Matthias Peick schrieb: > Nein, hilft mir leider genauso wenig, wie das APT-Howto. Es steht > zwar in beiden drin, wie man etwas tut, aber nicht, warum man das > macht. Die Frage nach dem Sinn bleibt dem Uneingeweihten > unbeantwortet.
Der technische Sinn von Pins in /etc/apt/preferences ist, die Installation einer ganz bestimmten Version eines Pakets festlegen zu können. Normalerweise wird anhand der Versionsnummern grundsätzlich die höchste, verfügbare Version genommen. Wobei die verfügbaren Versionen anhand der Einträge in der sources.list bestimmt werden. Trägt man dort Beispielsweise _alle_ Quellen für stable, testing und unstable ein, hat man zwangsläufig ein System, dass auf dem Versionsstand von unstable läuft. Und gäbe es zusätzlich in stable Pakete, die in unstable mittlerweile entfernt wurden, wären diese Pakete in der Version von stable im Angebot der Paketliste. Mit Pins kann man nun festlegen, dass das System trotzdem auf dem Versionsstand von stable laufen soll (Pin für stable >1000). Dann werden Pakete aus stable nicht automatisch mit Paketen aus testing/unstable aktualisiert. Analog zu obigem Szenario hat man dann ein stable-System und zusätzlich Pakete aus testing/unstable zur Verfügung. Das Theater beginnt sobald man eines der zusätzlichen Pakete oder ein bestimmtes Paket in der Version aus z.B. testing installieren möchte. Diese Paket ist dann beispielsweise von einer neueren Version einer Library aus testing abhängig. Diese Lib wiederum kann nur zusammen mit einer neueren Version der zentralen Systembibliothek libc6 arbeiten. Und so kommt es, dass man Ruck-Zuck auf dem Versionstand von testing sein muss, damit das gewünschte überhaupt in der neuen Version installiert oder funktionieren kann. Ein Mix zwischen stable und testing/unstable ist nur mit sehr simplen Paketen aus testing/unstable zu arrangieren, wie z.B. Shell-Skripten (apt-proxy) oder Doku-Paketen. Pins sind häufiger verwendbar bei einem System auf dem Versionsstand von testing, wenn man bei einzelnen Paketen dem Stand von unstable folgen möchte. Oder anders gesagt, es bleibt vom ürsprünglichen woody nicht mehr viel übrig, wenn Du die genannten Pakete alle installieren möchtest. Ganz streng genommen gilt das auch für an woody angepasste Pakete. Stable bedeutet bei Debian, dass an dieser Distribution und Zusammenstellung nichts mehr geändert wird und alles im bekannten stabilen Zustand belassen wird. Nur Sicherheitsupdates und Korrekturen für gravierende Bugs werden nachträglich eingespielt. Stable und "die neueste Version haben will" widerspricht sich also schon vom Grundgedanken. Stable Systeme setzt Du ein, wenn ein Dienst am Internet hängt und die nächsten paar Jahre seine Arbeit machen soll. Testing ist das, was die meisten anderen als die stabile Distribution in Schachteln packen. Die Versionen sind vergleichbar aktuell, im Moment mit Ausnahme der grossen Brocken XFree 4.2, KDE3, u.ä. Das dauert eben ein wenig länger. Ein Grund dafür ist, dass Debian nicht nur für Intel 32-Bit-Plattformen erscheint, sondern für knapp ein dutzend Architekturen. In Testing kommen alle Pakete aus unstable, für die die Abhängigkeiten stimmen und bei denen eine gewisse Zeit (normal 10 Tage) kein neuer Bug-Report dazu kam. Bei Testing kann es Dir alle paar Monate passieren, dass nach einem Update eine Software nicht mehr richtig will und man korrigierend eingreifen oder auf den vorigen Stand zurückgehen muss. Beides geht nicht automatisch und daher sind organisatorische Vorkehrungen (Backup vor dem Update, lokaler Proxy), als auch über "apt-get upgrade" hinausgehende Kenntnisse hilfreich. Wobei ich will den Anpruch nicht zu hoch hängen. Die passende Mailingliste zu konsultieren gehört schon zu den weitergehenden Kenntnissen. Unstable sind die Pakete, die die Maintainer erfolgreich gepackt und hochgeladen haben. Da es die Prüfbedingungen für testing nicht gibt, ist es ein wenig der grosse Kochtopf. Hier gibt es keine Garantie, dass alles zusammen passt oder reibungslos funktioniert. Hier solltest Du das Debian-System detailliert verstehen. Wäre sinnvoll, wenn Du Paket- oder Installationsfehler zumindest selber analysiert bekommst, um einen passenden Bug-Report absetzen zu können. Salopp formuliert, sollte der unstable Benutzer sich selbst helfen können. Letztendlich ist das auch der Sinn (und somit eine Art der Beteiligung am Debian-Projekt), damit anderen zu helfen, indem die Probleme in unstable abgefangen werden und testing erst gar nicht erreichen. -- [EMAIL PROTECTED] -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
