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)
