Newsgroup: it.comp.os.linux.debian
Titolo: apt-get e kernel

Ciao a tutti.
Uso da non molto debian ed ho notato, da subito, che facendo apt-get
upgrade spesso e volentieri
viene proposto anche l'aggiornamento del kernel.
Il problema è che viene proposta la stessa versione di quella già
installata (con tanto di avviso da parte di dpkg).
Sapete dirmi il perchè?
Forse vengono aggiornati dei moduli ed il kernel invece viene
mantenuto sempre alla stessa versione?
E per aggiornare i moduli, forse ripacchettizzano tutto il kernel...
Mah.

 Sapete dirmi il perchè?
Non e` esattamente lo stesso.
E` la stessa versione (2.6.18, per esempio) del kernel vanilla, ma 
vengono applicate patch diverse (e raramente opzioni diverse di 
compilazione). Infatti cambia il numerino finale (2.6.18-6, 2.6.18-7, 
2.6.18-8, ecc.).
apt-get ti avvisa perche` i moduli vanno a finire nella stessa directory 
(/lib/modules/2.6.18/...), e quindi ti consiglia di riavviare per evitare 
di caricare moduli che potrebbero essere incompatibili con il vecchio 
kernel.
Bye.

 ha scritto nel messaggio 
news:6j1n43F...@mid.individual.net...


 kernel.
Il discorso non fa un granzia, ma come detto sopra: mi sembrava di
aver
visto lo stesso patch level.

 nelle precedenti versioni di Debian questa cosa venisse fatta di default.
Ma non mi da fastidio, ma che senso può avere aggiornare lo stesso
kernel con lo
stesso patch-level?
Forse come ho detto per un eventuale update dei moduli?
Ma l'update di un modulo del kernel, non dovrebbe incrementare la
versione del kernel
o quanto meno il suo patch-level?
Mi spiego: se il kernel 1.1.1 ha la versione 0.1 del modulo X, quando
questo modulo X
viene aggiornato alla versione 0.2, dato che fa parte del kernel,
anche il kernel dovrebbe
cambiare versione in 1.1.2 visto che è stato modificato.
No?

 la mia domanda, infatti.
I kernel sono una mezza rogna, in Debian, come versionamento :)
# dpkg -l|grep linux-image
ii  linux-image-2.6.22-3-amd64           2.6.22-6.lenny1
ii  linux-image-2.6.24-1-amd64           2.6.24-7
ii  linux-image-2.6.25-2-amd64           2.6.25-7
ii  linux-image-2.6.26-1-amd64           2.6.26-4
Come vedi, non ce n'e` uno che abbia nel nome la stessa versione. Quello 
che cambia e` appunto la versione (2.6.26-4, e non 2.6.26-1)
Bye.

 installata (con tanto di avviso da parte di dpkg).
A volte il kernel viene aggiornato per motivi di sicurezza, ma non
essendoci grosse modifiche gli eventuali moduli aggiuntivi compilati
(es. nvidia) restano compatibili.
In questo caso la versione del kernel non viene cambiata, ma il
pacchetto avanza di versione.
È quindi importante effettuare l'aggiornamento.
-- 
Lurkos

 pacchetto avanza di versione.
Be, ma questo va contro ogni logica.
Se il software viene modificato anche di un singolo punto, BISOGNA
cambiare
versione, altrimenti prima o poi si diventa scemi a ricordarsi le
variazioni, anche se piccole.
Quindi tu mi dici che il kernel a volte fa modifiche anche senza
cambiare versione?
Ed io che volessi scaricarne uno come faccio?
Supponendo che io abbia un vanilla 1.2.3, gli sviluppatori del kernel
aggiungono un
puntino nel codice, rilasciano la versione senza incrementarla. Dopo 1
mese io vado
a vedere su 
kernel.org
 se è uscito il kernel nuovo, vedo che la
versione è la stessa
e me ne vado senza update quando invece era necessario farlo.

 variazioni, anche se piccole.
Occhio, qui si parla di DUE versioni differenti:
$ dpkg -l linux-image-2.6.26-1-686 | grep ^ii
ii  linux-image-2.6.26-1-686             2.6.26-5 [..]
Quella che NON viene incrementata, per motivi futili, è quella presente nel nome
del pacchetto, ossia la versione del *kernel* (patchato): quindi, 2.6.26-1.
Quella che viene SEMPRE e COMUNQUE incrementata (fermo restando la stessa
versione nel nome) è la versione del *pacchetto*: 2.6.26-5.
In sostanza:
a) linux-image-2.6.26-1-686 -- versione 2.6.26-4
b) linux-image-2.6.26-1-686 --          2.6.26-5
c) linux-image-2.6.26-2-686 --          2.6.26-1
a e b hanno *stessa* versione del kernel, ma differenti versioni del pacchetto
(i.e. il -5 ha nuovi moduli, nuove opzioni di config, [..])
a e c hanno *diversa* versione del kernel, quindi probabilmente ci sono nuove
patch.
(almeno, dovrebbe esser così la cosa.)
HTH,
David
-- 
 . ''`.  Debian maintainer | 
http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- 
http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- 
http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 variazioni, anche se piccole.
Viene cambiata la versione del pacchetto linux-source-XXXX oppure del
pacchetto linux-patch-debian-XXXX usati per generare il pacchetto binario
linux-image-XXXX
Inoltre come già ti hanno fatto notare c'è differenza tra il NOME del
pacchetto e la sua versione.
Non capisco perché tu debba pensare che gli sviluppatori Debian siano tutti
degli idioti.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 degli idioti.
Come scusa?
E chi l'avrebbe mai pensato?
Non mettermi in bocca parole che non ho mai detto.
Ho fatto solo una domanda e mi è stato risposto:
"A volte il kernel viene aggiornato per motivi di sicurezza, ma non
essendoci grosse modifiche gli eventuali moduli aggiuntivi compilati
(es. nvidia) restano compatibili.
In questo caso la versione del kernel non viene cambiata, ma il
pacchetto avanza di versione."
Che si può intendere anche come: il kernel non avendo subito grosse
modifiche ma solo qualche miglioria in termini di sicurezza, non
avanza di versione.
Come se fossero i moduli a decidere della versione del kernel: se il
modulo viene
aggiornato, si avanza di versione, altrimenti no.
QUESTO (il kernel, non debian) è fuori ogni logica se così fosse.
(e mi sembra quasi impossibile)
E comunque sia, da qui, a dire che sono tutti idioti, di acqua ne
passa...

 modulo viene aggiornato, si avanza di versione, altrimenti no.
Cosa c'entrano i moduli?
Come dovresti sapere alcuni parti possono essere compilate come modulo o
integrate nel kernel e quindi quello che dici è privo di senso.
Il kernel è uno e comprende tutti i moduli compilati dai suoi sorgenti
(almeno nella concezione del pacchetto Debian associato).
Discorso diverso per i moduli esterni non forniti con il kernel.
-- 
Lurkos

 incrementarla.
Non essendoci la versione di sviluppo 2.7, le correzioni di sicurezza e
le nuove funzionalità confluiscono assieme nelle versioni stabili 2.6.
-- 
Lurkos

 Discorso diverso per i moduli esterni non forniti con il kernel.
Tu hai detto che se ci sono piccole modifiche, il kernel (inteso come
linux-2.6.XX.YY.tar.gz)
non avanza di versione. Se invece le modifiche sono più sostanziali ed
i moduli potrebbero
non essere più compatibili, allora in quel caso si avanza.
Quindi, la versione dipende strattamente dalla compatibilità dei
moduli. Se le modifiche
potrebbero rompere la compatibilità con i moduli, allora si avanza,
altrimenti nisba.
E' questo che, IMHO, non ha senso.
Se il kernel viene modificato anche in piccola barte, bisognerebbe
avanzare di versione.
IMHO.

 le nuove funzionalità confluiscono assieme nelle versioni stabili 2.6.
Ok, ma supponiamo io abbia la versione 2.6.1.
Qualcuno degli sviluppatori fa una modifica, aggiunge un printf
completamente inutile.
La nuova versione sarà la 2.6.2 o sempre 2.6.1?
Dal tuo discorso sarà sempre la 2.6.1 quindi io non sarò mai in grado
di sapere se è stata modifica rispetto alla mia 2.6.1 scaricata due
settimane prima.

 settimane prima.
Devi distinguere tra mainstream e "pacchettizzatori".
Se i programmatori mainstream aggiungono una riga al codice, passano da 
2.6.1 a 2.6.2. A quel punto i pacchettizzatori (chiamiamoli pacc e pacc2) 
dovranno fare un nuovo pacchetto che si chiama "linux-image-2.6.1-1" 
versione 2.6.1-1.
Ora metti che il pacc si accorge di un problema nel kernel e lo corregge, 
oppure vuole applicare la patch "overclock_cpu.patch". Prende la stessa 
versione del kernel (2.6.1) e ci applica la patch, rilasciando pero` un 
nuovo pacchetto nella distro (2.6.1-2). Dopo un po' pacc2 vede che quella 
patch non e` eccezionale e vuole toglierla. Rifa` il pacchetto e gli mette 
la versione 2.6.1-3.
Il pacchetto continua a chiamarsi "linux-image-2.6.1-1" ma la sua versione 
e` 2.6.1-3
Poi arrivano gli sviluppatori mainstream e si accorgono che pacc ha 
committato upstream la sua patch, la mettono nel kernel e lo chiamano 
2.6.1.23.
A questo punto pacc e pacc2 devono rifare il pacchetto, lo chiamano "linux-
image-2.6.1-2" e gli mettono versione 2.6.1-1, ricominciando la conta (e` 
cambiato il nome del pacchetto, quindi e` come se fosse completamente 
diverso).
Bye.

 Dal tuo discorso sarà sempre la 2.6.1
Ma non è vero!
Non ho mai parlato di upstream!
-- 
Lurkos

 diverso).
Sai che non ti ho capito?
Credo che tu abbia fatto un po di confusione con i numeri, oppure sono
io che sono fuso (più probabile)

 avanzare di versione.
Hai capito la differenza fra versione del kernel e versione del
pacchetto?
Secondo me ti devi rileggere tutto da capo con calma.
-- 
Lurkos

 Non ho mai parlato di upstream!
Intendo per il cambiamento di versione *del pacchetto*.
-- 
Lurkos

 Non ho mai parlato di upstream!
Allora, esempio stupido.
2.MAJOR.MINOR.PATCHLEVEL
2.1.2.3
debian chiamerà il pacchetto:
linux-image-2.1.2-1  <=== l'1 è al versione del PACCHETTO.
Poi arriva un tizio sviluppatore che fa una patch al kernel, la quale
viene accettata ed inclusa nel kernel stesso.
La versione sarà quindi:
2.1.2.4
debian come lo chiamerà sto pacchetto?
linux-image-2.1.2-2
Insomma, se ho capito giusto, dato che il pacchetto del kernel su
debian è a 3 numeri, quindi non conta il patchlevel, eventuali update
intesi come patch (patch ufficiali del kernel e non customizzazioni
debian) incrementeranno solo la versione del pacchetto.
-2, -3, -4
La versione del pacchetto include tutte le patch ufficiali del kernel
vanilla + tutte le customizzazioni.
Quando viene rilasciato un nuovo vanilla, si riparte da 1 ma con
versione kernel aggiornata.

 io che sono fuso (più probabile)
No, ha detto proprio bene.
-- 
Lurkos

 linux-image-2.1.2-1  <=== l'1 è al versione del PACCHETTO.
Sbagli.
$ dpkg -l linux-image-2.6.26-1-686
[..]
ii  linux-image-2.6.26-1-686          2.6.26-5 
$
"2.6.26-1" è la versione "upstream" del kernel, ed è quella nel *nome* del
pacchetto -- in Debian si tengono solo i primi 3 numeri, e il patch level si
indica con -X, nel *nome* *del* *pacchetto*.
La versione che vedi con dpkg -l è la versione del *pacchetto*, che viene
incrementata *sempre* (fermo restando il nome del pacchetto): modifiche in
debian/, patch del manutentore, ...
In conclusione: è come ha scritto Alessandro Pellizzari :)
Ciao,


 debian/, patch del manutentore, ...
Quindi il kernel attuale, presente su 
kernel.org
 (2.6.26.5) se volessi
pacchettizzarlo
diventerà:
linux-image-2.6.26-5-686 ?
il 5 (patchlevel del kernel) da anche la versione del pacchetto
debian?

 debian?
No. (nessuno qui c'ha capito nulla, allora, compreso me).
Dando un'occhiata al changelog [0]:
/----
| linux-2.6 (2.6.26-5) unstable; urgency=low
|  ..
|  * Add stable release 
2.6.26.4
:
|    ..
| linux-2.6 (2.6.26-4) unstable; urgency=low
|  ..
|  * Add stable release 
2.6.26.3
:
|    ..
| linux-2.6 (2.6.26-3) unstable; urgency=low
|  ..
| linux-2.6 (2.6.26-2) unstable; urgency=low
|  ..
|  * Add stable release 
2.6.26.1
:
|    ..
|  * Add stable release 
2.6.26.2
:
|    ..
| linux-2.6 (2.6.26-1) unstable; urgency=low
| 
|  * New upstream release see 
http://kernelnewbies.org/Linux_2_6_26
|    ..
\----
Quindi, siamo alla 2.6.26.4, eppure il pacchetto continua a chiamarsi
linux-image-2.6.26-1-*.
Dando un'occhiata al "Debian Kernel Handbook" [1], si ha [2]:
/----
| linux-image[-subarch]-version-abiname-flavour
| 
|     This package contains the binary kernel image and pre-built binary modules
|     for a particular arch/subarch/flavour combination. [..]
\----
Quindi, quel numeretto, è l'ABI [3]:
/----
| Kernel ABI is the exported binary interface provided by the kernel, and
| accompanying modules. Most Linux distributions have a way of tracking this ABI
| to detect when the kernel's exported interfaces have changed, and thus,
| modules compiled for it may be in need of recompiling. Usually this results
| in the incrementing if an ABI number (on Ubuntu, it would be the "-2-" in
| 2.6.24-2-generic).
\----
Ecco. Il risultato finale :)
Google is always our friend.
Saluti,
David
[0] 
http://changelog.debian.net/linux-2.6
[1] 
http://kernel-handbook.alioth.debian.org/
[2] 
http://kernel-handbook.alioth.debian.org/ch-packaging.html
[3] 
http://blog.phunnypharm.org/2008/06/kernel-abi-and-why-it-matters.html


 Quindi, quel numeretto, è l'ABI [3]:
Ok, quindi a parità di versione, la compatibilità dei moduli si valuta
con il numero ABI.
MA:
il patchlevel quindi non viene mai indicato?
Se il 4° numero è l'abi, la versione 2.6.26.5 come la indico?
Stando al manuale:
linux-image-2.6.21-[ABI]-686.deb (forse)

 linux-image-2.6.21-[ABI]-686.deb (forse)
Bravo.


 No.
Benissimo, ed io come faccio a sapere l'equivalente vanilla del mio
kernel?
Ad esempio se il mio kernel pacchettizzato fosse 2.6.21-1 (l'1 abbiamo
detto che è l'ABI)
ed io volessi verificare se sono all'ultimo patch-level presente su
kernel.org
 o meno,
come ci arrivo alla versione vanilla esatta?

 | less
  * Add stable release 
2.6.26.4
:
  [..]
$
Certo, si fa affidamento al changelog.. ma serve anche a questo :)
Questa mi sembra l'unica soluzione, anche perché il patchlevel non c'è
neppure nei sorgenti del kernel... (ho controllato nel Makefile, all'inizio..
non saprei dove altro cercare)
David
