Hallo Liste,
Der aufmerksame Leser weiß, ich versuche individuelle Kernel als deb unter debian-Systemen zu verteilen. Der Prozess die Kerne zu aktualisieren/bauen und in einem repository bereitzustellen steht soweit. Sagen wir das Paket heißt "ronnys-kern" und hat die Version w.x-y. Sobald ich am Paket etwas ändere wird neu versioniert und bereitgestellt unter Version w.x-z. aptitude auf einem Client merkt nun, dass eine andere, neuere Version verfügbar ist. Bis hierher ist alles wie es sein soll.
Wie verhindere ich, dass das Einspielen des verfügbaren Updates Dateien aus der Vorgängerversion entfernt? Konkret /boot/vmlinuz-w.x-y usw. Da muss sich doch in Der Struktur des deb (conffiles?) irgendetwas einstellen lassen.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo Ronny
Am 10.08.2011 16:00, schrieb Ronny Seffner:
Wie verhindere ich, dass das Einspielen des verfügbaren Updates Dateien aus der Vorgängerversion entfernt? Konkret /boot/vmlinuz-w.x-y usw. Da muss sich doch in Der Struktur des deb (conffiles?) irgendetwas einstellen lassen.
~# cat /etc/apt/apt.conf.d/01autoremove APT { NeverAutoRemove { "^firmware-linux.*"; "^linux-firmware$"; "^linux-image.*"; "^kfreebsd-image.*"; "^linux-restricted-modules.*"; "^linux-ubuntu-modules-.*"; };
Ich denke, du mußt das apt hier mitteilen.
Gruß Rico
Hallo Rico,
NeverAutoRemove
Leider scheint dieser Parameter nicht wirklich dokumentiert, aber die zugehörige gleichnamige Funktion von apt* "autoremove" entfernt ja Pakete, die einst in Abhängigkeiten mit installiert wurden und ggf. nicht mehr benötigt werden.
Mir geht es konkret darum den "neuen " Kern einzuspielen und dabei den "alten" zu behalten. Dabei soll das deb immer gleich heißen und sich nur in der Version unterscheiden, da sonst ein 'aptitude upgrade/dist-upgrade' nichts von der Existenz des neuen Paketes mitbekommen würde.
Eine mir unliebe Lösung wäre, jedes neue Paket würde alle "alten" Versionen beinhalten.
Vielleicht wird es verständlicher, wenn ich den Workflow skizziere:
- ich erstelle einen individuellen Kern, paketiere und verteile - es gibt eine Anpassung für diesen Kern, die über den update Mechanismus von apt verteilt werden soll - der Client soll den aktuell laufenden Kern behalten und den neuen zusätzlich installieren - dabei wird lilo mit dem Schalter "-R" angewiesen, den neuen Kern nur einmalig zu "probieren", damit es ein fallback auf den alten Zustand geben kann - da ich nicht sicherstellen kann, dass der Client unbedingt den direkten Vorgänger des Kerns einsetzt, kann ich auch nicht die beiden neuesten Kerne ins deb stecken
Wie verhält sich dpkg denn bei einem Update? - uninstall des alten Paketes incl. pre- und postrm? - install des neuen Paketes incl. pre- und post-inst? = dann könnte man (dirty) ja im prerm eine Kopie temporär sichern, die im pre- oder postisnt wiederzuholen ist ...
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Ronny Seffner schrieb:
NeverAutoRemove
Leider scheint dieser Parameter nicht wirklich dokumentiert, aber die zugehörige gleichnamige Funktion von apt* "autoremove" entfernt ja Pakete, die einst in Abhängigkeiten mit installiert wurden und ggf. nicht mehr benötigt werden.
Mir geht es konkret darum den "neuen " Kern einzuspielen und dabei den "alten" zu behalten. Dabei soll das deb immer gleich heißen und sich nur in der Version unterscheiden, da sonst ein 'aptitude upgrade/dist-upgrade' nichts von der Existenz des neuen Paketes mitbekommen würde.
Du probierst einen unsinnigen Weg, der *gewollt* standardmäßig nicht funktioniert. Ein "purge" *muss* alle Dateien eines Pakets entfernen. Dateileichen sind schwerwiegende Fehler im Sinne der Debian Policy. Und mit dem Problem müsstest du dich dann auch rumschlagen, also Dateien händisch entfernen.
Was du willst lässt sich doch ganz leicht skripten. Der Paketname muss nur eine fortlaufende Nummer erhalten. Schreib dir eine debian/control.in, lass das Skript die Nummer aus meinetwegen Paket "mein-kern-X" auslesen, um eins erhöhen und in die debian/control.in (via sed o.ä.) eintragen. Mittels /usr/bin/dch passt du den changelog-Eintrag an und lässt das Skript das Paket bauen.
Gleichzeitig kannst du ein virtuelles Paket mit immer gleichem Namen erstellen, meinetwegen "mein-kern": apt-cache show equivs. Dort schreibst du auch eine control.in und dieses Paket lässt du von "mein-kern-X" abhängen. dch hilft dir wieder, den changelog-Eintrag zu machen. Das Skript passt hier also das Depends-Feld an (wieder sed o.ä.).
Beide Pakete packst du in dein Repositorium. Wenn du "mein-kern" installiert hast, zieht das bei eigener Aktualisierung immer das neue Kernel-Paket nach sich und du kannst alte Pakete auch frei von dateileichen entfernen.
So würde ich das machen und nicht versuchen, die Grundsätze des Paketmanagements auszuhebeln. Wenn du Hilfe bei den Skripten brauchst, schreib einfach.
MfG und HTH Daniel
Hallo Daniel,
Gleichzeitig kannst du ein virtuelles Paket mit immer gleichem Namen
erstellen, ...
in die debian/control.in (via sed o.ä.) eintragen. Mittels /usr/bin/dch
Also ich baue die Pakete mit 'dpkg-deb -b *' und setze die von Dir erwähnten "devscripts" (noch?) nicht ein - das sollte aber erst mal egal sein. Folgen wir mal dem sehr guten meta-package Gedanken:
Ich bauen nun meine Kerne als "priv-kernel-3.0-1", später "priv-kernel-3.0-2" (immer "Package: priv-kernel-3.0" in control) und "priv-kernel-3.0.1-1" sowie "priv-kernel-3.0.1-2" (je "Package: priv-kernel-3.0.1") jeweils in arch "i386" und "amd64". Die Versionen "*-1" zu "*-n" spiegeln nur andere Optionen beim Bauen der Kerne wider, wobei die Versionen "3.0-x" und "3.0.1-x" das vanilla Versionsschema abbilden. Dazu habe ich ein Paket "priv-kernel-3.0" in arch "all" mit "Depends: priv-kernel-3.0". Dieses Paket installiert sollte nun "priv-kernel-3.0-1" fordern. Sobald im repo auch "priv-kernel-3.0-2" ankommt, gibt es ein Update, welches Dateien überschreibt, das wäre gewollt. Wenn mein "priv-kernel-3.0.1-1" erscheint muss ich auch die Abhängigkeit im Metapacket anpassen auf "Depends: priv-kernel-3.0.1" und es gibt für den Client nun "priv-kernel-3.0.1-1" zu installieren, welches den "priv-kernel-3.0" in Ruhe ließe. Soweit zur Theorie ;-)
meinetwegen "mein-kern": apt-cache show equivs. Dort schreibst du auch
Praktisch habe ich Obiges so umzusetzen versucht und nun das Problem, dass der Client das Metapaket gar nicht sieht - im Repo ist es vorhanden. Jetzt schreibst Du von "equivs"; sollte das nicht genau das tun, was ich "manuell" versucht habe? Erscheint mein Paket nicht, weil es "leer" ist?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Praktisch habe ich Obiges so umzusetzen versucht und nun das Problem, dass der Client das Metapaket gar nicht sieht - im Repo ist es vorhanden.
"Architecture: all" ist ja ok, es aber im Repository unter "squeeze-non-free-all" abzulegen war wohl falsch.
Dafür habe ich neuen "Ärger" mit dieser metapackage-Idee: nachdem mein metapackage "priv-kernel" nun den "priv-kernel-x" erfordert hat, ist jetzt ein "priv-kernel-y" verfügbar. In jugendlichem Leichtsinn habe ich also "Depends: " in "priv-kernel" aktualisiert, was dem apt-Client erfreulich die Verfügbarkeit von "*-y" liefert. Doch bei dessen Installation priv-kernel-y{a} wird die Deinstallation priv-kernel.x{u} fällig. Beide in "Depends: " aufnehmen will ich aber nicht.
Was übersehe ich jetzt?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Rico Koerner rico@netbreaker.de (Wed Aug 10 20:17:06 2011):
~# cat /etc/apt/apt.conf.d/01autoremove APT { NeverAutoRemove { "^firmware-linux.*"; "^linux-firmware$"; "^linux-image.*"; "^kfreebsd-image.*"; "^linux-restricted-modules.*"; "^linux-ubuntu-modules-.*"; };
Ich meine, autoremove ist etwas anderes, es hat nichts mit den Files innerhalb der Pakete zu tun, sondern mit Paketen als solchen.
Die sollen auch nicht entfernt werden, wenn das Paket, welches die Instalation über eine Abhängigkeit „verursacht“ hat, wieder entfernt wird.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 11.08.2011 09:59, schrieb Heiko Schlittermann:
Rico Koerner rico@netbreaker.de (Wed Aug 10 20:17:06 2011):
~# cat /etc/apt/apt.conf.d/01autoremove APT { NeverAutoRemove { "^firmware-linux.*"; "^linux-firmware$"; "^linux-image.*"; "^kfreebsd-image.*"; "^linux-restricted-modules.*"; "^linux-ubuntu-modules-.*"; };
Ich meine, autoremove ist etwas anderes, es hat nichts mit den Files innerhalb der Pakete zu tun, sondern mit Paketen als solchen.
Die sollen auch nicht entfernt werden, wenn das Paket, welches die Instalation über eine Abhängigkeit „verursacht“ hat, wieder entfernt wird.
Ronny wollte doch ein neues Kernelpaket für die nächste Version bauen. Ich bin davon ausgegangen, daß das Kernelimage darin eine entsprechend hochgezählte Version hat und die Datei des alten Images nicht überschreiben würde. Das alte Image (also das alte Paket) sollte bei der Installation des neuen nicht deinstalliert werden. Genau das passiert ja bei mir auch. Ich hab linux-image-2.6-amd64 (meta-package) installiert und das alte Paket bleibt bei mir immer drin und ich werf es nach erfolgreichem Neustart manuell raus.
Ich bin davon ausgegangen, daß NeverAutoRemove genau das bewirkt und daß es das ist, was gesucht war.
Liegt die Lösung dann vielleicht in dem zusätzlichen Meta-Package?
Gruß Rico
Ronny Seffner ronny@seffner.de (Wed Aug 10 16:00:33 2011):
Der aufmerksame Leser weiß, ich versuche individuelle Kernel als deb unter debian-Systemen zu verteilen. Der Prozess die Kerne zu aktualisieren/bauen und in einem repository bereitzustellen steht soweit. Sagen wir das Paket heißt "ronnys-kern" und hat die Version w.x-y. Sobald ich am Paket etwas ändere wird neu versioniert und bereitgestellt unter Version w.x-z. aptitude auf einem Client merkt nun, dass eine andere, neuere Version verfügbar ist. Bis hierher ist alles wie es sein soll.
Wie verhindere ich, dass das Einspielen des verfügbaren Updates Dateien aus der Vorgängerversion entfernt? Konkret /boot/vmlinuz-w.x-y usw. Da muss sich doch in Der Struktur des deb (conffiles?) irgendetwas einstellen lassen.
Der Sinn des Updates ist es, das Vorgängerpaket zu entfernen (seine Files) und dafür neue Files hinzulegen.
Wenn Du conffiles hast, werden diese ggf. ersetzt, wenn sie ihre Prüfsumme nicht verändert haben.
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
Heiko Schlittermann -
Rico Koerner -
Ronny Seffner