[Eisfair] kernel 4.9.255 testing

[Marcus Röckrath]

Hallo,


Marcus Röckrath wrote:

> Schau in eiskernel-virt rein:
> 
> <require-package>base 2.8.25</require-package>
> <require-package>glibc 3.0.1</require-package>
> <require-package>linux-kernel-4.9.255-virt 3.0.3</require-package>
> 
> Das eiskernel-virt-Metapaket enthält eigentlich nur die requires, um auf
> den aktuellen Kernel upzudaten.
> 
> Kommt ein neuer Kernel, wird also hier das require auf den neuen Kernel
> eingesetzt.

Vielleicht noch etwas ausführlicher:

Jede Kernelversion ist eine eigenständiges Paket; es trägt die Version des
Kernels mit im Namen.

Dadurch können nach Bedarf auch ältere Kernel installiert und verwendet
werden.

Wenn nun ein neuer Kernel mit der Version 4.9.257 käme, ist das kein Update
für den jetzigen 4.2.255. Daher würde auch bei dessen erscheinen dieser den
vorigen nicht ersetzen, sondern er wird dann zusätzlich installiert.

Wird eine gleiche Kernelversion aktualisiert, also z. B. der jetzige 4.9.255
auf den Status stable gebracht oder wegen einer Korrektur neu gebaut,
bleibt der Name des Paketes gleich (linux-kernel-4.9.255-virt) und ersetzt
beim Update das vorige Paket gleichen Namens.

Hierbei wird, damit es als Update erkannt wird, natürlich die interne
Paketnummer (derzeit 3.0.3) erhöht.

Ein Kernelupdate ersetzt somit nicht mehr eine ältere Kernelversion, wie es
früher war. Wurde zweimal der gleiche Kernel installiert, waren danach eis
und oldeis identisch, also der Rettungsanker" auf den vorigen Kernel weg.

Um nur innerhalb einer Kernelversion upzudaten, braucht es die Metapakete
nicht.

Um also ein Update auf eine neue Kernelversion als Update angeboten zu
bekommen, braucht es nun die Metapakete, denn wenn die "als Update kommen",
verweisen sie auf den nächsten Kernel, also eventuell auf 4.9.257.

Die Versionsnummer der Metapakete ist bei 6.x, da sie ja auch bei den von
Thomas betreuten Kernelpakete bei 5.x angekommen waren; das sind die
Versionsnummern der eisfair-Pakete nicht des Kernels.

Die Kernelpakete haben eine eigene interne Versionsnummerierung. Das die bei
3.x nun beginnt, hat keine besonderen Gründe, sondern ist nur angelehnt an
die glibc-Version (interne eisfair-Versionsnummer der aktuell verwendeten
glibc), um hier eine klare Zuordnung zu haben.

Übrigens gab es für die AVM/DAHDI-Kernelmodule immer schon versionierte
Pakete, die unabhängig voneinander waren.

-- 
Gruß Marcus
[eisfair-Team]