Szenario: In einer versionsgesteuerten Systemkonfiguration basierend auf Puppet, Chef usw. muss ein bestimmter Systemstatus reproduziert werden. Dies erfolgt durch explizite Angabe von Systempaketversionen.
Kürzlich stießen wir auf ein Problem, bei dem bestimmte Paketversionen in den Debian-Repositories fehlten. Ein Beispiel: Das "Patch" -Paket war in Version 2.7.5-1 + deb9u1 erforderlich, aber nur 2.7.5-1 + deb9u2 war verfügbar. Ein weiteres, noch schwerwiegenderes Beispiel: "linux-headers-4.9.0-9-common" ist erforderlich (da der zugehörige Kernel installiert ist) und nur "linux-headers-4.9.0-11-common" ist verfügbar.
Dies macht es unmöglich, einen bestimmten Zustand eines Systems zu reproduzieren.
Die obigen Pakete sind nur Beispiele (auf die ich tatsächlich gestoßen bin). Ich bin daran interessiert, das allgemeine Problem zu verstehen und zu lösen.
Welche Idee steckt hinter diesen Updates, verschwindenden Paketen und Paketversionen?
Wo kann ich frühere Versionen (nicht wirklich alte Versionen, aber Versionen, die ein paar Wochen alt sind) von Debian-Paketen bekommen? Es sollte möglich sein, den Installationsprozess allgemein zu automatisieren.
stable
bleibt konsistent, zumindest bis zur nächsten Punktveröffentlichung. stable-updates, testing und unstable enthalten nur die neueste Version eines bestimmten Pakets. Für alles andere, werden Sie auf suchen, um archive.debian.org (oder snapshot.debian.org wie in SK Antwort erwähnt)
linux
Paketname ist eine Ausnahme: Im Allgemeinen haben die Pakete von Debian Stable denselben Paketnamen und ändern nur die Versionsnummer. linux-image-amd64
ändert nie den Namen und hängt immer vom neuesten ab linux-image-4.9.0-*
. Der neue linux-image-4.9.0-*
pkg-Name markiert die inkompatiblen Kernel-ABI-Änderungen, die für das Backportieren einiger Bugfixes erforderlich sind, und ermöglicht die erforderliche Neukompilierung von benutzerdefinierten Modulen (dkms usw.). Ähnliches gilt für linux-headers-*
.
apt-get changelog packagename