Aktuelle Version vom 6. November 2024, 12:32 Uhr

Apt-Pinning ist eine Möglichkeit bestimmte Paketquellen bevorzugt zu behandeln

Beschreibung

So kann man z. B. bei einer LTS-Version bleiben, aber gezielt Pakete von einer neueren Version oder einer anderen inoffiziellen Quelle beziehen.

Oder man kann an einem Paket in einer bestimmten Version festhalten und somit dessen Aktualisierung oder Deinstallation verhindern.

Konfiguration

Das Pinning erfolgte früher traditionell in der Datei /etc/apt/preferences.
Seit Ubuntu 10.04 sollte man den Ordner /etc/apt/preferences.d/ nutzen, in dem man eine neue Datei mit einem beliebigen Namen anlegt.
Idealerweise enthält der Dateiname dann einen Hinweis auf die jeweilige Paketquelle.
Diese Datei darf entweder die Dateiendung .pref oder aber keine Endung besitzen (z. B. xenial.pin würde ignoriert werden).
Unabhängig vom Speicherort muss das Anlegen und die Bearbeitung mit einem Editor [1] mit Root-Rechten [2] erfolgen.

Pinning

Bevor Sie über 'Pinning' nachdenken, sollten Sie prüfen, ob das Paket bereits für ihre Version in Debian Backports bereitgestellt wurde.
Wenn Apt-Pinning benutzt wird, müssen Sie die Kompatibilität der Pakete selbst überprüfen, da Debian dies nicht garantiert. Bedenken Sie, dass Apt-Pinning völlig optional ist und Debian schlägt dessen Verwendung nicht ohne gründliche Überlegung vor.
Pinning erlaubt es Ihnen gewisse Pakete aus einer bestimmten Version zu verwenden (Stable, Testing, Unstable), ohne die Notwendigkeit das ganze System zu aktualisieren.
In der einfachsten Variante werden für Pinning zwei Dateien benötigt, /etc/apt/sources.list und /etc/apt/preferences.
Eine zusätzliche Rolle spielt die Zielveröffentlichung (Target Release) welche in /etc/apt/apt.conf (oder in einer Datei unterhalb /etc/apt/conf.d/... und der Apt-Kommandozeile) gesetzt werden kann.

/etc/apt/sources.list

#### testing  #########
deb http://ftp.us.debian.org/debian testing main contrib non-free
#### unstable #########
deb http://ftp.us.debian.org/debian unstable main contrib non-free

In diesem Beispiel laden wir von Testing und Unstable herunter. Sie können dies natürlich dahingehend abändern, dass auch aus Stable geladen wird.

/etc/apt/preferences

Package: *
Pin: release n=testing
Pin-Priority: 900
Package: *
Pin: release n=unstable
Pin-Priority: 800

Option	Beschreibung
Package	ist hier Standard für alle Pakete, angegeben durch den Stern
Pin	gibt die Veröffentlichung (Release) an (Testing und Unstable)
Pin-Priority	gibt die Priorität an

'apt-get' hat die Voreinstellung, dass die Pakete mit höchster Priorität "gewinnen". Das obige restrukturiert diese Priorität, sodass Pakete aus Testing eine höhere Priorität bekommen.

Weiteres können Sie im apt_preferences(5) Handbuch nachlesen.

Installation von Unstable

Lassen Sie uns annehmen, dass wir Testing verwenden und wir Enlightenment aus Unstable möchten. Es gibt grundsätzlich zwei Methoden für die Installation:

# apt-get install enlightenment/unstable
# apt-get -t unstable install enlightenment

Das erste Beispiel wird nicht versuchen irgendwelche Pakete auf Ihrem System zu aktualisieren; wenn bestimmte Abhängigkeiten verletzt werden, schlägt die Installation fehl. Die zweite Methode wird versuchen, jegliche Abhängigkeiten zu aktualisieren/installieren. Bei der obigen Prozedur wird Sie 'apt-get' natürlich vor dem Fortfahren fragen.

Anmerkungen

Ich persönlich fand die übliche Konfiguration mit Testing mit höherer Priorität und Unstable mit niedrigerer Priorität problematisch. Manchmal hängen Testingpakete von Paketen ab, die momentan nicht in Testing sind (eventuell ein Beispiel für kurzzeitige Störungen), was dazu führt, dass Pakete einfach automatisch aus Unstable gezogen werden. Im Zeitraum von Testing vor der Stabilisierung für die stabile Version Woody, führte dies dazu, dass über 100 Unstable-Pakete installiert waren, ohne dass man dies wusste.

Das Resultat ist, dass ich eine konservativere "Nur wenn ich es sage"-Herangehensweise für eine gemischte Distribution verwende mit ungefähr so einer Pin-Datei:

 Package: *
 Pin: release a=testing
 Pin-Priority: 900
 Package: *
 Pin: release o=Debian
 Pin-Priority: -10

Daraus ergibt sich, dass alle Debianpakete standardmäßig eine Priorität von -10 haben, während Testing einen Bonus von 900 erhält. Das führt zu folgendem Verhalten:

Aus apt_preferences(5)

      500 < P <=990
          veranlasst, dass eine Version installiert wird, außer wenn eine Version verfügbar ist, die zum Ziel-Release gehört oder die installierte Version neuer ist
 [...]
      P < 0
          verhindert das Installieren der Version

Anmerkung: Eine Priorität über 1000 sogar die Installation einer älteren Version ermöglicht (Downgrade), egal welche Priorität das Paket hat. Das bedeutet, dass Sie die Priorität 1001 für eine stabile Quelle (Stable) nutzen können, wenn Sie ältere (stabile) Versionen der installierten Pakete für Ihr System wünschen (beispielsweise von Testing). Dies wird nicht empfohlen, außer die Anzahl der Änderungen ist gering.

Die Installation mittels apt-get install paketname/unstable und apt-get install -t unstable paketname werden beide weiterhin funktionieren, aber nur Pakete aus Unstable werden durch diese Kommandos installiert.

Anmerkungen

Das englischsprachige Original dieser Seite wurde von ZugSchlus geschrieben, welcher nicht einmal entfernt das Konzept von Pinning versteht.

Nehmen Sie daher die Worte "wahrscheinlich", "muss bestätigt werden" und ähnliche Ausdrücke wörtlich und dokumentieren Sie Ihre Funde (mögen diese auch "diese Seite stimmt" oder "diese Seite liegt falsch", optional "diese Seite liegt falsch in Hinsicht auf ...") sein, hier.
Die Deutsche Übersetzung ist irreführend und verwirrend. Bitte die englische Variante lesen.

Paketauswahl

Dies muss überprüft werden

Ignoriere Pakete, welche nicht das Kriterium der Version haben
Ignoriere Pakete mit niedrigerer Version als die aktuelle, außer die Priorität liegt über 1000
Installiere das übriggebliebene Paket, welches die höchste Priorität hat
Im Falle einer Gleichheit der Prioritäten, nimm das "gepinnte" Paket
- Dieser Schritt sollte wahrscheinlich übersprungen werden, wenn die Auswahl auf nichts passt
Im Falle ohne Vorauswahl (Pin), nehme höchstpriorisiertes Paket
In dem Fall mehrerer Pakete gleicher Version, nimmt Apt-get jenes, welches als erstes in sources.list aufgeführt ist

Beispiele:/etc/apt/preferences

Beispiel

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 900
Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300
Package: *
Pin: release o=Debian
Pin-Priority: -1

ZugSchlus versucht zu erklären:

Alle Pakete einer Distribution genannt Testing werden auf 900 gesetzt
Alle Pakete von einer Distribution genannt Unstable werden auf 300 gesetzt
Alle anderen Pakete von Debian bekommen die Priorität 1 und werden daher nie installiert

Problem

Diese Beschränkung kann sich anders verhalten, abhängig von der gesetzten Zielveröffentlichung in anderen Teilen der Apt-Konfiguration.
Daher kann dieses Beispiel nicht wirklich dokumentiert werden, ohne mehr Informationen hinzuzufügen.
Ein nicht beschränktes Paket welches ein Teil der Zielveröffentlichung hat die Standardpriorität 990, während andere nicht beschränkte Pakete lediglich eine Priorität von 500 haben.

Beispiel 2

Ziel
Ziehe auf einem Unstable-System Dpatch von Experimental

Eine mögliche (und nicht völlig korrekte) Lösung:

Unstable und Experimental sind in sources.list
- Mit der Abwesenheit von einer expliziten Beschränkung (Pin) wird Experimental automatisch auf die Priorität 1 gesetzt. Das liegt daran, dass die Veröffentlichungsdatei von Experimental NotAutomatic: yes (nicht-automatisch: ja) enthält.
Priorisieren Sie die gewünschten Pakete auf einen Wert x mit 100<x<500:
Package: dpatch
Pin: release o=Debian,a=experimental
Pin-Priority: 450
- Ein Wert > 500 wird immer ein Paket aus Experimental auswählen, verhindern dass ein höher nummeriertes Paket aus Unstable installiert wird und "gar kein Paket" auswählen, bevor allen verfügbaren Paketen, wenn die Distribution, die nicht dieses Paket enthält, eine höhere Priorität besitzt.
- Unglücklicherweise versteht das Paket-Feld weder Wildcards noch Regular Expressions. Sie benötigen einen Absatz pro Paket.
- Wenn das Paket auf 450 gesetzt ist, wird es wohl nicht automatisch auf ein neueres Paket aus Experimental aktualisiert werden, aber es wird das Paket in experimental solange behalten, wie die Version in Unstable nicht höher ist.

Beispiel 3

Nehmen Sie an, dass Sie ein eigenes Repositorium haben, wo Sie eine persönliche Version von Postfix haben.
Sie wünschen von Apt, dass es Ihre Version vor offiziellen bevorzugt.

Sie können die Einstellungen auf "origin" (Herkunft) setzen:

Package: *
Pin: origin www.rktmb.org
Pin-Priority: 610

Package: *
Pin: origin ftp.fr.debian.org
Pin-Priority: 600

Fehlersuche

apt-cache policy package liefert Informationen über den Auswahlprozess. Leider ist nicht allgemein bekannt, was die Ausgabe meint. Das folgende ist ein Interpretationsversuch:

$ apt-cache policy exim4-daemon-light
exim4-daemon-light
 Installiert: 4.50-1
 Kandidat: 4.50-1
 Paket-Pin: (nicht gefunden)
 Versionstabelle:
     4.50-4 555
       500 http://mirror sid/main Packages
 *** 4.50-1 555
       100 /var/lib/dpkg/status
     4.44-2 555
       500 http://mirror sarge/main Packages

Die Priorität jeder Version/jedes Ortes ist die Nummer links davon. In diesem Fall 500, 100, 500. Es ist unklar, was die Nummer rechts von der Versionsnummer bedeutet. Einige Leute glauben, dass es lediglich die letzte Periode für das Paket ist, welche in /etc/apt/preferences für das Paket angegeben wurde, während andere glauben, es sei die tatsächliche Beschränkungspriorität des Pakets.

ToDo: Dieser Abschnitt wurde nach mehr oder weniger wissenden Annahmen geschrieben. Könnte dies jemand mit realer Kenntnis über Apt bitte nachprüfen?

Anmerkungen

Wenn Sie sich aufgrund des Links http://www.debian.org/doc/manuals/repository-howto/repository-howto fragen, was die Optionen für Veröffentlichungsdaten basierend auf obigen Link sind, so finden wir:

Archive: Archiv
Component: Komponente
Origin: Ihre Firma
Label: Ihr firmeneigenes Debian-Repositorium
Architecture: Architektur

Daher würde die Zeile "Pin: release a=testing" Archivwerte in der Veröffentlichungsdatei finden, welche Testing heißt.

Anwendungen

Beispiel

/etc/apt/sources.list

## Offizielle Quellen
deb http://archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
## Inoffizielle Quelle
deb http://peters-ubuntupakete.example.org/ubuntu/ xenial main restricted universe multiverse

Pinning per Release

Hinweis: Grundsätzlich definiert eine Leerzeile einen neuen Abschnitt für einen weiteren Eintrag. Leerzeilen zwischen Package, Pin und Pin-Priority sind nicht erlaubt!

Beispiel

/etc/apt/preferences.d/xenial

Package: *
Pin: release v=16.04, l=Ubuntu
Pin-Priority: 1000

Von nun an haben alle Pakete aus offiziellen Paketquellen für die Version 16.04 und dem Distributionsnamen (Label) Ubuntu Vorrang, selbst wenn es in anderen Quellen neuere Pakete gibt.

Eine Formulierung wie Pin: release a=xenial hätte nicht ausgereicht, da es ja auch Paketquellen von Ubuntu 16.04 gibt, die xenial-security, xenial-updates etc. heißen.
Erst wenn es Pakete dort nicht gibt, werden diese (soweit verfügbar) aus anderen Quellen installiert.
Die verschiedenen Parameter für Pin: release werden im Abschnitt Parameter für Pinning per Release weiter unten erläutert.

Pinning nach Ursprung

Beispiel

/etc/apt/preferences.d/peters-ubuntupakete

Package: *
Pin: origin peters-ubuntupakete.example.org
Pin-Priority: 300

Dieser Fall setzt die Priorität für eine bestimmte Internetadresse (origin).
Die genaue Bedeutung der Pin-Priority wird im Abschnitt Werte für Pin-Priority weiter unten erläutert.

Pinning per Version

Der Dateiname für eine bestimmte Programmversion lautet z. B. /etc/apt/preferences.d/hello:

Package: hello
Pin: version 2.1.1*
Pin-Priority: 1000

Dieses Beispiel verhindert die Installation des Paketes hello in einer neueren Version als 2.1.1, aber auch die unbeabsichtigte „automatische“ Deinstallation aufgrund von Konflikten.

Parameter für Pinning per Release

Unix	GNU	Beschreibung
a	archive	Name des Repositories
c	Bereich eines Repositories
v	version	Version des Repositories/Veröffentlichung
o	origin	"Erzeuger" des Repositories
l	label	Name der Distribution

Die genauen Werte können mittels des Befehls apt policy nachgeschlagen werden.

Hier ein Ausschnitt aus der Ausgabe dieses Kommandos:

 25 http://packages.medibuntu.org bionic/free Packages
    release v=18.04,o=Medibuntu,a=bionic,l=Medibuntu,c=free
    origin packages.medibuntu.org
500 http://ppa.launchpad.net/mozillateam/ppa/ubuntu bionic/main Packages
    release v=18.04,o=LP-PPA-mozillateam,a=bionic,n=bionic,l=Firefox ESR and Thunderbird stable builds,c=main
    origin ppa.launchpad.net
500 http://de.archive.ubuntu.com bionic/main Packages
    release v=18.04,o=Ubuntu,a=bionic,l=Ubuntu,c=main
    origin de.archive.ubuntu.com
[.....]

Mit Pinning verwaltete Pakete

firefox-esr-locale-de -> 52.9.0esr+build2-0ubuntu0.18.04.1 mit Priorität 1000
firefox-esr -> 52.9.0esr+build2-0ubuntu0.18.04.1 mit Priorität 1000
[.....]

Die Werte aus den release-Zeilen können ganz oder teilweise zum Pinning übernommen werden.

Werte für Pin-Priority

Die Werte für Pin-Priority in der Datei /etc/apt/preferences müssen positive oder negative ganze Zahlen sein. Sie werden wie folgt interpretiert:

Pin-Priority	Beschreibung
> 999	Version wird in jedem Fall installiert, auch wenn das einen Downgrade des Paketes nach sich zieht
990 - 999	Version wird installiert, auch wenn sie nicht zum Release gehört, es sei denn ein aktuelleres Pakete ist bereits installiert
500 - 989	Version wird installiert, es sei denn, es gibt eine Version, die zum Release gehört oder eine aktuellere Version ist bereits installiert
100 - 499	Version wird installiert, es sei denn, es gibt eine aktuellere die nicht zum Release gehört oder die bereits installierte Version ist aktueller
1 - 99	Version wird nur dann installiert, wenn es keine bereits installierte gibt
negativer Wert	Version wird nicht installiert

Das Paket mit der höchsten Punktzahl wird immer bevorzugt.

Experten-Info: Ausführlichere Informationen hierzu findet man in der Manpage von apt_preferences oder im APT HOWTO

Überprüfung

Die Wirkung des Apt-Pinnings auf bestimmte Pakete kann mit folgendem Befehl überprüft werden:

# apt policy PAKETE

Gezielte Umgehung mit apt-get

Im Terminal [2] kann man mit apt-get gesetzte Prioritäten aber auch gezielt umgehen.

Folgender Aufruf installiert z. B. das Programm MPlayer aus dem Paketbereich xenial (Ubuntu 16.04). Dabei werden Abhängigkeiten nach der Priorität erfüllt.

# apt-get -t xenial install mplayer-custom

apt-mark - Aktuelle Version behalten

# apt-mark hold firefox

Dieser Befehl setzt die aktuell installierte Firefox Version auf "Halten", ist also identisch mit dem Pin auf die aktuelle Version. Um das automatische updaten wieder zu erlauben gibt man den folgenden Befehl ein:

sudo apt-mark unhold firefox

Beispiele

Von proposed-Quellen downgraden

Mit Pinning gibt es eine vergleichsweise einfache Möglichkeit, ungewollte Upgrades auf Pakete aus den proposed-Quellen rückgängig zu machen, sprich auf die herkömmlichen und i.d.R. gut getesteten Pakete bzgl. Installationsroutine und Systemintegration downzugraden.
Zuerst deaktiviert man die proposed-Quellen [3] und aktualisiert die Paketindexdateien.

Dann legt man die Datei /etc/apt/preferences/no-proposed an:

Package: *
Pin: release a=ARCHIV*
Pin-Priority: 1001

Dabei ist ARCHIV durch den Codenamen der jeweiligen Ubuntu-Version zu ersetzen.
Codenamen sind beispielsweise trusty, xenial usw.
Nach dem Codenamen sollte ein Stern * gesetzt werden, damit auch Pakete aus den Quellen ARCHIV-updates und ARCHIV-security berücksichtigt werden.

Anschließend kann ein Upgrade bzw. Downgrade der Pakete durchgeführt werden:

# apt-get dist-upgrade

Nachdem die Paketversionen korrigiert wurden, sollte die Pinning-Datei wieder entfernt werden, damit irgendwann in Zukunft ein Upgrade auf eine neuere Ubuntu-Version ohne Probleme möglich ist.

Einzelne Pakete aus älterer/neuerer Version installieren

Mitunter möchte man eine aktuellere Version eines Pakets aus der nächsten Ubuntu-Version nutzen, ist aber nicht bereit, ein komplettes Upgrade zu machen.
Oder aber man hat ein Upgrade hinter sich, die neue Version eines Programms verursacht jedoch Probleme und man würde lieber für dieses eine Paket zur früheren Version zurückkehren.
Die Methode mit Apt-Pinning entspricht im Prinzip dem manuellen Herunterladen und Installieren der entsprechenden Pakete von http://packages.ubuntu.com, ist aber deutlich bequemer, besonders wenn verschiedene Abhängigkeiten ebenfalls einen Up- bzw. Downgrade erfordern.

Achtung: Die Verwendung von Paketen aus anderen Ubuntu-Versionen kann im Einzelfall eine pragmatische Lösung sein, in der Regel ist aber davon abzuraten. Besonders bei einer großen Zahl an Abhängigkeiten sind Probleme vorprogrammiert.

Beispiel

Das Paket subversion (siehe SVN) liegt für Ubuntu 16.04 (xenial) in der Version 1.6.17 und für Ubuntu 17.04.10 (zesty) in der Version 1.7.5 vor.

Nach einem Upgrade auf Ubuntu 17.04 möchte man zur Version 1.6 des Pakets zurückkehren.

Dazu fügt man den Paketquellen folgende Zeile hinzu [3]:

deb http://archive.ubuntu.com/ubuntu xenial main
deb-src http://archive.ubuntu.com/ xenial main
deb http://archive.ubuntu.com/ xenial-updates main
deb http://archive.ubuntu.com/ xenial-security main

Nun wird in der Datei /etc/apt/preferences folgender Inhalt ergänzt (bzw. die Datei neu angelegt)

Package: subversion
Pin: version 1.6*
Pin-Priority: 1001

Package: *
Pin: release v=16.04, l=Ubuntu
Pin-Priority: -1

Nun kann nach Aktualisieren der Paketlisten mit apt-get update das Paket subversion aus den Quellen von Ubuntu 16.04 installiert werden [4].
Wurde es bereits installiert, wird mit apt-get dist-upgrade automatisch die ältere Version installiert.
Unter Umständen müssen je nach Komplexität der Abhängigkeiten noch weitere Pinning-Einträge hinzugefügt werden.

Einzelne Pakete aus einem Sammel-PPA installieren

Bei der Verwendung eines Personal Packages Archiv (PPA) tritt immer wieder das Problem auf, dass nach dem Einbinden und Aktualisieren nicht nur das gewünschte Programm, sondern - je nach PPA - eine ganze Reihe weiterer Programme in den Paketquellen auftaucht, die u.U. mit den Versionen aus den offiziellen Paketquellen kollidieren können.
Die Nutzung dieser Sammel-PPAs kann deutlich vereinfacht werden, in dem man nur das oder die gewünschten Pakete aus einem PPA zulässt (und allen anderen blockiert).
Zwingende Voraussetzung: das Paket hat keine speziellen Abhängigkeiten, die ebenfalls aus dem PPA stammen müssen.

Dazu legt man - vor dem Installieren des Pakets - eine Datei /etc/apt/preferences.d/LP-BENUTZER-PPA-NAME mit Root-Rechten und folgendem Inhalt an (LP-BENUTZER-PPA-NAME und Paketnamen bitte anpassen):

Package: *
Pin: release o=LP-PPA-LP-BENUTZER-PPA-NAME
Pin-Priority: -1

Package: foo
Pin: release o=LP-PPA-LP-BENUTZER-PPA-NAME
Pin-Priority: 500

Package: bar
Pin: release o=LP-PPA-LP-BENUTZER-PPA-NAME
Pin-Priority: 500

Während der erste Abschnitt die Nutzung des PPAs praktisch untersagt, gilt dies nicht für die gewünschten Pakete foo und bar.

Konfiguration

Dateien

Sicherheit

Siehe auch

APT/Pinning

Dokumentation

RFC

Man-Page

man 5 apt_preferences

Info-Pages

Links

Projekt

Weblinks

Apt-Howto (Abschnitt 3.10) und AptPinning.
http://www.xs4all.nl/~carlo17/howto/debian.html#errata
apt_preferences(5) Benutzerhandbuch (Manpage)
Apt-Pinning for Beginners - eine gute Referenz, von der heftig geborgt wurde.
APT HOWTO Abschnitt 3.10
http://www.argon.org/~roderick/apt-pinning.html
Debian Referenz über apt-pinning

TMP

APT Pinning

Eine besondere Stärke des Debian Paketmanagements ist, dass unterschiedliche Release-Stände verwendet werden können.

Hierzu sind zumindest zwei Releases (beispielsweise „woody“ und „testing“) mit entsprechenden Einträgen in der Datei /etc/apt/sources.list anzugeben.
Nun kann mittels apt-get --target-release der gewünschte Release-Stand für ein Paket gewählt werden.

Sinnvoll einsetzbar ist dieses Feature leider nur mit zwei Releases; werden drei Debian Releases (beispielsweise zusätzlich „unstable“) oder aber eine Nicht-Debian Paketquelle gemischt, so kommt es zu seltsamen Ergebnissen.

Die Lösung für dieses Problem ist eine Erweiterung der Datei /etc/apt/preferences.

Hier zunächst ein Beispiel für eine sinnvolle /etc/apt/preferences-Datei.

Auf den meisten Systemen wird diese Datei nicht existieren (sie wird auch nicht zwingend benötigt) und muss daher neu angelegt werden.

#      * Track stable:
Explanation: see http://www.argon.org/~roderick/apt-pinning.html
Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 900

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 400

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300

Package: *
Pin: release o=Debian
Pin-Priority: -1
     * Track testing:
Explanation: see http://www.argon.org/~roderick/apt-pinning.html
Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 900

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300

Package: *
Pin: release o=Debian
Pin-Priority: -1

Bereits beim einmaligen Aufruf von apt-get kann mit der Option -t der Wert für „APT::Default-Release“ gesetzt werden.

Diese Einstellung gilt jedoch lediglich für diesen einen Aufruf von apt-get.
Beispiel: apt-get -t unstable install paketname.
Dies kann durchaus ein sehr nützliches Feature sein, kann sich aber in anderen Fällen auch problematisch auswirken.

Die gute Seite: Sind in der sources.list die Releases testing und unstable definiert und ist in der Datei apt.conf der Wert für APT::Default-Release auf „testing“ gesetzt, so ergeben sich folgende Prioritäten für das Paket „foo“:

#    release    version        priority
                        no -t switch       -t unstable
   testing      1.1          990               500
   unstable     1.2          500               990

Ist das Paket „foo“ nicht installiert und wird apt-get install foo aufgerufen, so wird die Version 1.1 aus „testing“ installiert, da diese die höchste Priorität hat.

Mittels apt-get -t unstable install foo kann gezielt die Version 1.2 aus „unstable“ installiert werden, da für diesen einen Aufruf von apt-get die Priorität erhöht wird.

Übrigens kann auch die Ausgabe des Kommandos apt-cache policy (ohne weitere Parameter) als Gerüst für eine eigene Datei /etc/apt/preferences dienen:

# apt-cache policy
Paketdateien:
 100 /var/lib/dpkg/status
     release
 500 http://security.debian.org testing/updates/main Packages
     release o=Debian,a=testing,l=Debian-Security,c=main
 500 http://ftp2.de.debian.org testing/main Packages
     release o=Debian,a=testing,l=Debian,c=main
     origin ftp2.de.debian.org
Festgehaltene Pakete (»Pin«):

Die Manpage zu dieser Konfigurationsdatei wird mittels man apt_preferences 5 angezeigt und enthält weitere Inform

TMP

Prioritäten

Voreingestellte Prioritäten

Ist keine APT-Konfigurationsdatei oder kein Eintrag in der Konfigurationsdatei vorhanden, der auf ein Paket passt, so wird für dieses Paket die voreingestellte Priorität verwendet, welche der Distribution entspricht.

Es besteht die Möglichkeit, ein bestimmtes Ziel-Release festzulegen, aus dem die Pakete installiert werden sollen.
Diese Distribution wird als „Target Release“ bezeichnet.
Das Ziel-Release kann dem Programm apt-get auf der Kommandozeile übergeben werden oder in der Konfigurationsdatei /etc/apt/apt.conf(siehe apt.conf) gesetzt werden.

Auf der Kommandozeile wird das Ziel-Release wie folgt angegeben:

# apt-get install -t testing paketname

Wurde ein Ziel-Release angegeben, so nutzt APT den folgenden Algorythmus, um die Prioritäten eines Paketes zu ermitteln.

Priorität 100	Wenn das Paket bereits installiert ist.
Priorität 500	Wenn das Paket nicht installiert ist und auch nicht zum Ziel-Release gehört.
Priorität 990	Wenn das Paket nicht installiert ist und zum Ziel-Release gehört.

Wird das Ziel-Release nicht angegeben, so vergibt APT die Priorität 100 an alle installierten Pakete und die Priorität 500 an alle nicht installierten Pakete.

Danach folgt APT den nachfolgend angeführten Regeln, wobei die Regeln in der beschriebenen Reihenfolge abgearbeitet werden. # Ein Paket wird niemals mit einer kleineren Versionsnummer installiert (Downgrade), wenn die Priorität unter 1001 liegt. „Downgrade“ bedeutet, dass eine nicht aktuelle Version eines Paketes installiert wird, obwohl bereits eine aktuelle Version des Paketes installiert ist.
Keine voreingestellte Priorität innerhalb von APT übersteigt den Wert 1000, ein solcher Wert kann ausschließlich über die Voreinstellungsdatei (preferences) gesetzt werden.
Der Downgrade eines Paketes ist in jedem Fall als problematisch anzusehen und sollte nach Möglichkeit vermieden werden.
In vielen Fällen führt ein Downgrade zu einem nicht funktionierenden Paket oder gar zu schweren Problemen mit dem Gesamtsystem.

Das Paket mit der höchsten Priorität wird installiert.
Wenn zwei oder mehrere Versionen eines Paketes die gleiche Priorität haben, so wird die Version mit der höchsten Versionsnummer installiert.
Wenn zwei oder mehr Versionen eines Paketes die gleiche Priorität und Versionnummer haben, aber die Pakete sich in den Metadaten unterscheiden, oder aber die Option --reinstall auf der Kommandozeile angegeben ist, so wird das nicht installierte Paket ausgewählt.

Am häufigsten ist die Situation anzutreffen, dass ein bereits installiertes Paket (Priorität 100) in einer Version installiert ist, die nicht so aktuell (hoch) ist wie ein Paket, welches über eine Quelle in der Datei /etc/apt/sources.list (Priorität 500 oder 990) verfügbar ist.

Dieses Paket wird aktualisiert, wenn das Kommando apt-get install paketname oder apt-get upgrade ausgeführt wird.

Seltener tritt der Fall ein, dass ein bereits installiertes Paket in einer aktuelleren Version vorhanden ist und kein Paket aus einer der in der Datei /etc/apt/sources.list genannten Quellen eine höhere Versionsnummer aufweist.

In diesem Fall wird kein Downgrade durchgeführt, wenn das Kommando apt-get install paketname oder apt-get upgrade ausgeführt wird.

Manchmal ist die bereits installierte Version eines Paketes aktueller als die zum Ziel-Release gehörende Version, jedoch nicht so aktuell wie ein Paket, welches aus einer anderen Distribution verfügbar ist.

In diesem Fall wird das Paket durch das Kommando apt-get install paketname oder apt-get upgrade aktualisiert, da eine der verfügbaren Versionen eine höhere Priorität besitzt als die aktuell installierte Version.

Verwenden von Voreinstellungen

Die APT Konfigurationsdatei /etc/apt/preferences erlaubt dem Administrator, die Zuweisung von Prioritäten detailliert zu steuern.

Die Konfigurationsdatei besteht aus Einträgen, die sich über mehrere Zeilen erstrecken und untereinander durch Leerzeilen getrennt sind.
Die Einträge beziehen sich auf ein einzelnes Paket (spezifische Form) oder auf eine Anzahl von Paketen (generelle Form). # Die spezifische Form weist einem Paket eine (Pin-)Priorität zu und übergibt dabei eine gewünschte Version oder einen Versionsbereich.
Das folgende Beispiel weist allen Versionen des Paketes perl eine hohe Priorität zu, solange die Versionsnummer mit „5.8“ beginnt.
Package: perlPin: version 5.8*Pin-Priority: 1001

Die generelle Form setzt eine Priorität für die angegebene Distribution oder für alle Pakete von einem bestimmten Server, welcher über den vollen Domainnamen (FQDN) identifiziert wird.
Diese generelle Form wirkt sich ausschließlich auf Gruppen von Paketen aus.

Folgendes Beispiel weist allen Paketversionen auf einem lokalen Repository mit Paketen eine hohe Priorität zu.
Package: *Pin: origin ""Pin-Priority: 999
Zu beachten ist hier das Schlüsselwort „origin“.
Dieses entspricht nicht dem gleich lautenden Begriff in einer „Release“-Datei! In einer „Release“-Datei wird mit dem Schlüsselwort „origin“ ein Autor oder Hersteller (beispielsweise „Debian“ oder „Ximian“) beschrieben, nicht eine Internetadresse.
Der folgende Eintrag setzt eine geringe Priorität für alle Paketversionen, die zu einer als „unstable“ bezeichneten Distribution gehören.
Package: *Pin: release a=unstablePin-Priority: 50
Das letzte Beispiel zeigt einen Eintrag, der eine hohe Priorität allen Paketen zuweist, die zum Release „stable“ gehören und eine Versionsnummer von „3.0“ aufweisen.
Package: *Pin: release a=unstable, v=3.0Pin-Priority: 50

Bewertung von Prioritäten

Prioritäten (P), die in der APT-Konfigurationsdatei vergeben werden, müssen positive oder negative Integerzahlen sein.

Diese werden wie folgt interpretiert.

P > 1000	Installiert ein Paket, auch wenn dies ein „Downgrade“ des Paketes bewirkt.
990 < P <= 1000	Installiert ein Paket, auch wenn es nicht aus dem „Target“-Release stammt, außer die bereits installierte Version ist aktueller.
500 < P <= 990	Installiert ein Paket, wenn kein Paket passend zum „Target“-Release vorhanden ist oder die bereits installierte Version aktueller ist.
100 < P <= 500	Bewirkt, dass eine Version installiert wird, solange keine andere Version aus irgeneiner anderen Distribution verfügbar ist oder aber die installierte Version aktueller ist.
0 < ? <= 100	Installiert eine Version eines Paketes nur, wenn dieses Paket noch nicht installiert ist.
P < 0	Verhindert, dass diese Version eines Paketes installiert wird.

Die Einträge werden in der aufgeführten Reihenfolge in der Konfigurationsdatei abgearbeitet.

Wird ein auf das Paket oder die Paketgruppe passender Eintrag gefunden, so werden die folgenden Einträge ignoriert.

Sind die vorab beschriebenen Einträge in einer Konfigurationsdatei in der beschriebenen Reihenfolge abgelegt, so ergibt sich folgende Konfigurationsdatei:

# Package: perl
Pin: version 5.8*
Pin-Priority: 1001

Package: *
Pin: origin ""
Pin-Priority: 999

Package: *

Pin: release unstable
Pin-Priority: 50

In dieser Zusammenstellung gelten folgende Regeln: # Es wird die aktuellste Version des Paketes „perl“ installiert, solange diese Version mit „5.8“ beginnt.

Ist eine Version 5.8 von Perl verfügbar und ist die Version 5.9 bereits installiert, so wird ein „Downgrade“ durchgeführt.

Jedes andere Paket, welches nicht das Paket „perl“ ist und auf dem lokalen System verfügbar ist, bekommt eine höhere Priorität.

Dies bewirkt, dass nur wenige, nicht lokal verfügbare Pakete aus dem Netz installiert werden.
Dies betrifft auch Versionen des „Target“-Release.

Ein Paket, welches nicht auf dem lokalen System verfügbar ist, aber in einer Quelle in der Datei /etc/apt/sources.list aufgeführt wird und zu einem „unstable“ Release gehört, wird nur installiert, wenn es zur Installation ausgewählt wird und noch keine Version dieses Paketes installiert ist.