Gli aggiornamenti incrementali del kernel sono distribuiti come patch
("toppe"). Per esempio, se si ha la versione 1.1.45 e si ha notizia
che c'è un `patch46.gz' in giro, significa che si può
aggiornare alla versione 1.1.46 applicando quella patch. Prima può
essere una buona idea fare una copia di backup dell'albero dei
sorgenti (`make clean' e poi `cd /usr/src; tar zcvf
old-tree.tar.gz linux' creerà un archivio compresso).
Così, continuando con l'esempio precedente, si supponga di avere
`patch46.gz' in /usr/src. Si faccia cd in
/usr/src e si faccia `zcat patch46.gz | patch -p0'
(o `patch -p0 < patch46' se la patch non è compressa). Si
vedranno delle cose sfrecciare (o fluttuare, se il proprio sistema è
abbastanza lento) che dicono che sta provando ad applicare dei pezzi
(hunk) e quando ha o meno successo. Solitamente questa azione è
troppo veloce per poterla leggere e non si è troppo sicuri quando ha
funzionato o meno, quindi può essere un'idea usare l'opzione
-s con patch, che dice a patch di riportare
solo i messaggi d'errore. Per cercare le parti che non sono andate a
buon fine, si passi in /usr/src/linux e si cerchino i file
con estensione .rej. Alcune versioni di patch
(versioni più vecchie che possono essere state compilate con un
filesystem inferiore) lasciano i rifiuti (reject) con un estensione
#. Si può usare `find' per la ricerca:
find . -name '*.rej' -print
mostrerà nello standard output tutti i file residenti nella directory
corrente ed in ogni sottodirectory con estensione .rej.
Se tutto va a buon fine, di faccia un `make clean',
`config', e `dep' come descritto nelle sezioni 3 e 4.
Ci sono alcune altre opzioni per il comando patch. Come
menzionato prima, patch -s sopprimerà tutti messaggi tranne
quelli d'errore. Se si conservano i sorgenti del kernel in un posto
diverso da /usr/src/linux, patch -p1 (in quella
directory) applicherà correttamente la patch. Altre opzioni di
patch sono ben documentate nella pagina man.
(Nota: questa sezione fa riferimento principalmente a kernel piuttosto vecchi)
Il problema più frequente che era solito comparire era quando una
patch modificava un file chiamato `config.in' e questo non
sembrava più essere a posto perché lo si era modificato per adattare
le opzioni alla propria macchina. Di questo ora si tiene conto, si
potrebbe ancora incontrare con vecchie release. Per correggerlo, si
veda il file config.in.rej, e si veda cosa rimane della patch
originale. Le modifiche saranno tipicamente marcate con `+'
e `-' all'inizio della riga. Si vedano le righe là attorno e
si ricordi se erano stato impostate a `y' o `n'. Ora
si editi il config.in, e si cambi `y' in
`n' e `n' in `y' quando appropriato. Si
faccia un
patch -p0 < config.in.rej
e se finisce con successo, allora si può continuare con la
configurazione e la compilazione. Il file config.in.rej
rimarrà, ma si può cancellarlo.
Se si incontrano ulteriori problemi, si può aver installato una patch
``fuori uso''. Se patch dice `previously applied patch detected:
Assume -R?' (rilevata una patch applicata precedentemente: assumo
-R?), probabilmente si sta provando ad applicare una patch precedente
al numero di versione corrente; se si risponde `y' proverà a
degradare i sorgenti e molto probabilmente fallirà; sarà quindi
necessario prendere in blocco un nuovo albero dei sorgenti (che poteva
non essere una cattiva idea sin dall'inizio).
Per tornare indietro (disapplicare) di una patch, si usi `patch
-R' sulla patch originale.
La miglior cosa da fare quando le patch fanno realmente casino è di
partire ancora un albero dei sorgenti nuovo di zecca (per esempio, da
uno dei file linux-x.y.z.tar.gz), e ricominciare.
Già dopo poche patch, i file .orig cominciano ad
ammucchiarsi. Per esempio, un albero 1.1.51 che ho ripulito l'ultima
volta quand'era 1.1.48: rimuovendo i file .orig ho recuperato oltre
mezzo mega.
find . -name '*.orig' -exec rm -f {} ';'
se ne occuperà al vostro posto. Le versioni di patch che
usano # per i reject usano una tilde invece di
.orig.
Ci sono modi migliori per sbarazzarsi dei file .orig, che
dipendono da GNU xargs:
find . -name '*.orig' | xargs rm
o il ``abbastanza sicuro ma un po' meno prolisso'' metodo:
find . -name '*.orig' -print0 | xargs --null rm --
Esistono altre patch (io le chiamo ``non standard'') oltre a quelle che distribuisce Linus. Se le si applica, le patch di Linus potrebbero non funzionare correttamente e si dovrà o tornare indietro, correggere i sorgenti o la patch, installare un nuovo albero dei sorgenti, o una combinazione di queste cose. Ciò può divenire abbastanza frustrante, se non si vogliono modificare i sorgenti (con la possibità di risultati pessimi), si rimuovano le patch non standard prima di applicare quelle di Linus, o semplicemente si installi un nuovo albero. Poi, si può provare a vedere se le patch non standard funzionano ancora. Se non lo fanno, o si resta con il vecchio kernel, giochicchiando con la patch e i sorgenti per farli funzionare, o si aspetta (probabilmente elemosinando) che esca una nuova versione della patch.
Quanto comuni sono le patch che non sono nella distribuzione standard? Probabilmente se n'è sentito parlare. Ero avezzo ad usare la patch noblink per le mie console virtuali perché odio il cursore lampeggiante (questa patch è - o almeno era - aggiornata frequentemente per le nuove release del kernel). Con la maggior parte dei device driver sviluppati come moduli caricabili, la frequenza di patch ``non standard'' è diminuita significativamente.