|
Debian gibt es in mindestens drei verschiedenen sogenannten Releases (Veröffentlichungen): stable, testing und unstable.
| stable |
Die stabile Distribution ist die letzte, offiziell freigegebene Distribution von Debian.
Sie gilt - wie der Name schon sagt - als stabil und wird primär zur Verwendung empfohlen.
|
| testing |
Die Test-Distribution
enthält Pakete, die in einer stabilen Version noch nicht akzeptiert
werden, aber in der Warteschlange dafür stehen. Der Hauptvorteil
in der Verwendung dieser Distribution besteht darin, dass sie aktuellere
Versionen der Software bietet.
|
| unstable |
An der instabilen
Distribution findet die aktive Entwicklung von Debian statt. Diese
Distribution wird hauptsächlich von Entwicklern und Leuten genutzt,
die immer den aktuellen Stand der Entwicklung wollen.
|
Nun ist es so, daß
ein Vermischen der Releases nicht so ohne weiteres möglich
ist. Hat man einmal eine Distribution, ob stable, testing oder unstable
installiert und die Paketquellen entsprechend ausgewählt, versucht
Debian nur Pakete aus dem enstprechenden Zweig zu installieren.
Selbst das Angeben von mehreren Zweigen in der sources.list hilft
nicht. Dies dient der Stabilität, da das Mischen von Paketen
aus unterschiedlichen Zweigen zu inkonsistenzen führen kann.
Möchte man dennoch Pakete aus unterschiedlichen Zweigen installieren,
hilft das apt-Pinning.
Das Pinning
apt-Pinning nennt man
nun eine Technik, die bei Angabe von mehreren Quellen aus verschiedenen
Releases eine Quelle bevorzugen kann. So kann man zum updaten schön
bei stable bleiben, jedoch auch Pakete aus testing oder sogar unstable
installieren. Es erleichtert sozusagen das Mischen von Paketen aus
verschiedenen Releases, ohne die Notwendigkeit ein stable-System
nach unstable upgraden zu müssen um ein Paket aus dem unstable-Zweig
zu installieren. Sozusagen kann man alle übrigen Pakete stabil
halten, während man ein paar Pakete aus unstable installiert.
Dazu benötigt man
mindestens zwei Dateien:
/etc/apt/sources.list
/etc/apt/preferences
Zusätzlich kann noch die Datei /etc/apt/apt.conf ins
Spiel kommen. Die Dateien preferences und apt.conf können auch
fehlen, in dem Fall legt man sie einfach an. Gibt man sämtliche
Quellen, also stable, testing und unstable an, kann das den apt-Cache
sprengen. In diesem Fall wird die Datei apt.conf benötigt,
weil in ihr ein Eintrag getätigt wird, um den Cache zu vergrößern.
Dieser Eintrag sieht wie folgt aus:
APT::Cache-Limit "8388608";
In der sources.list fügt
man nun sämtliche Quellen die man haben will hinzu, z.B.
deb http://ftp2.de.debian.org/debian stable main contrib non-free
deb http://ftp2.de.debian.org/debian testing main contrib non-free
deb http://ftp2.de.debian.org/debian
unstable main contrib non-free
Im preferences-File findet das eigentliche pinning statt. Normalerweise
werden immer die aktuellsten Pakete installiert, aber mit dem Pinning
kann man dieses Verhalten ändern. Die Einträge in der
Datei preferences sehen wie folgt aus:
| Package:
* |
Das
Wildcard-Zeichen (*) steht für jedes Paket. |
| Pin:
release a=testing |
Pin
spezifiziert das Release. Folgende Parameter können für
das Pinnen mittels release verwendet werden:
a (archive) - Der Zweig eines Repositories z.B. stable
c (components) - Der Bereich eines Repositories z.B. main
v (version) - Version des Repositories bzw. der Veröffentlichung,
z.B. 3.1
o (origin) - Die Erzeuger des Repositories, hier Debian
l (label)
- Name der Distribution, hier auch Debian
|
| Pin-Priority:
900 |
Pin-Priority
spezifiziert den priority Level. |
Würde man nun ein
normales apt-get install paket ausführen, würde
es die Stable oder die Version installieren, die die höchste
Priorität besitzt (/etc/apt/preferences). Angenommen wir haben
ein testing installiert und wollen nun Pakete einer anderen Version
installieren, dann haben wir folgende zwei Möglichkeiten:
# apt-get install Paket/unstable
# apt-get -t unstable install Paket
Die erste Methode versucht die Abhängigkeiten aus dem eigentlichen
Release (in unserem Falle testing) zu erfüllen, was häufig
zu einer Fehlermeldung führt, weil die benötigten Pakete
fehlen.
Die zweite Methode löst die Abhängigkeiten aus dem angebenen
Release (in unserem Beispiel unstable), was eher zum Erfolg führt.
Beispiel um eine Distribution
auf stable zu halten:
| Package: * |
alle Pakete |
| Pin: release a=stable,v=3.0* |
installiert
nur Pakete für die stable version 3.0, aber trotzdem alle Sicherheits-Updates,
die als Version 3.0r1, 3.0r2, usw. erscheinen. |
| Pin-Priority: 1001 |
|
|
