Re: APT, Pinning und große Programme
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.
--
rainer@ellinger.de
Reply to: