Old:Modificare i cursori di X: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Old:Modificare i cursori di X (visualizza wikitesto)

Versione delle 17:35, 6 ago 2007

2 byte aggiunti ,  6 ago 2007
nessun oggetto della modifica
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 1: Riga 1:
== Introduzione ==
''Inserire qui la traduzione di [http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/appa.pdf questo] capitolo...''
Il [[repository]] � a tutti gli effetti un archivio ordinato dove sono raccolti i pacchetti Debian (siano essi pacchetti binari o sorgenti) in modo ben organizzato e costantemente aggiornato. In ogni sistema debian i repository utilizzati vengono indicati nel file <tt>/etc/apt/sources.list</tt>. Vedi anche [[Faq#Repository|FAQ: Cos'� un '''repository'''?]].


== Lista repository ufficiali debian ==
Di seguito troverete l'elenco repository ufficiali da inserire nel <tt>sources.list</tt> per le varie [[La struttura della Distribuzione|versioni di debian]]. Il mirror quello italiano. I repository dei pacchetti sorgente sono commentati. per ulteriori informazioni leggere la sezione: [[I repository ed il loro utilizzo#Sources.list|Sources.list]].


=== Vecchia Stabile: Debian Sarge ===
__TOC__
{{Warningbox|Sarge � ormai la vecchia stable. Usate Etch per le nuove installazioni}}
 
  ## Debian Stable (sarge)
Scaricare [da Internet, NdT], compilare, aggiornare e mantenere i sorgenti del kernel Linux coinvolge diversi passi, come questo libro illustra. Essendo per natura creature pigre, gli sviluppatori hanno creato alcuni programmi a supporto di queste attivit� di routine. Descriviamo alcuni di tali utili strumenti e le nozioni di base sul loro utilizzo.
  deb http://ftp.it.debian.org/debian/ sarge main contrib non-free
 
  #deb-src http://ftp.it.debian.org/debian/ sarge main contrib non-free
Lo sviluppo del kernel Linux differisce per molti aspetti dal tradizioale processo di sviluppo software. Ad uno sviluppatore del kernel sono richieste alcune attivit� peculiari:
 
  ## Aggiornamenti della sicurezza
* Applicare le modifiche ad un "bersaglio mobile" quale � il kernel, a causa della pianificazione dei rilasci di sviluppo.
  deb http://security.debian.org/ sarge/updates main contrib
* Risolvere i conflitti nella fase di merge tra ci� ha fatto rispetto a quanto fatto dagli altri sviluppatori.
  #deb-src http://security.debian.org/ sarge/updates main contrib
* Esportare i suoi cambiamenti in un formato che permetta agli altri sviluppatori di incorporarli facilmente nel proprio lavoro.
 
==patch e diff==
Questa sezione � basata su un articolo pubblicato originariamento su ''Linux Journal''.
 
Una delle modalit� pi� comuni per lavorare con il kernel � quella di usare i programmi ''patch'' e ''diff''. Per usare questi strumenti, sono necessarie due differenti directory: una "pulita" (clean) e una "di lavoro" (indicata con ''dirty'' in seguito). La directory clean contiene la versione originale del kernel, mentre quella di lavoro contiene le modifiche apportate dal programmatore alla stessa release.
Utilizzando ''patch'' e ''diff'' � possibile estrarre i cambiamenti apportati sul sorgente e portarli nella nuova release del kernel.
 
Per esempio, creiamo due directory contenenti l'ultima versione del kernel come descritto nel Capitolo 3.
 
<pre>
$ tar -zxf linux-2.6.19.tar.gz
$ mv linux-2.6.19 linux-2.6.19-dirty
$ tar -zxf linux-2.6.19.tar.gz
$ ls
linux-2.6.19/
linux-2.6.19-dirty/
</pre>
 
Ora � possibile apportare tutte le modifiche desiderate al sorgente presente nella directory di lavoro (dirty), lasciando inalterata quella clean. Dopo aver apportato le modifiche, si potr� creare una patch da inviare agli altri sviluppatori tramite i seguenti comandi:
 
<pre>
$ diff -Naur -X linux-2.6.19/Documentation/dontdiff linux-2.6.19/ \
linux-2.6.19-dirty/ > my_patch
</pre>
 
Questo comando creer� un file dal nome ''my_patch'' che conterr� tutti i cambiamenti apportati al sorgente del kernel rispetto alla versione pulita presente nella directory clean. Tale file potr� essere distribuito o inviato ad agli altri sviluppatori via email.
 
 
===Nuove versioni del kernel===
Al rilascio di una nuova versione del kernel, se si desidera portare i cambiamenti su questa nuova versione � necessario applicare la patch ad una versione ''pulita'' del kernel.
Questo pu� essere fatto seguendo questi passi:
* Creare la patch, come illustrato nell'esempio precedente.
* Utilizzare la patch ufficiale dal sito ''kernel.org'' e aggiornare la vecchia versione alla nuova release:
 
<pre>
$ cd linux-2.6.19
$ patch -p1 < ../patch-2.6.20
$ cd ..
$ mv linux-2.6.19 linux-2.6.20
</pre>
 
* Aggiornare la directory di lavoro rimuovendo la propria patch e, in seguito, applicando il nuovo aggiornamento:
<pre>
$ cd linux-2.6.19-dirty
$ patch -p1 -R < ../my_patch
$ patch -p1 < ../patch-2.6.20
$ cd ..
$ mv linux-2.4.19-dirty linux-2.6.20-dirty
</pre>
 
* Provare ad applicare la propria patch sul nuovo aggiornamento:
<pre>
$ cd linux-2.6.20-dirty
$ patch -p1 < ../my_patch
</pre>
 
Se l'applicazione della patch provoca dei problemi, � necessario risolvere i conflitti creati (il comando ''patch'' informer� circa questi conflitti creando i file ''.rej'' e ''.orig'' per l'analisi e la correzioni da parte dello sviluppatore).
Questo processo di ''fusione'' (''merge'') pu� rappresentare la parte pi� difficile dell'intero processo se sono stati apportati cambiamenti a porzioni di codice che sono state modificate anche da altri.
 
Per applicare correttamente questo processo di sviluppo, raccomando fortemente di utilizzare l'eccellente insieme di programmi ''patchutils'' (reperibile qui: ''http://cyberelk.net/tim/patchutils''). Questi programmi permettono di manipolare le patch facilmente e hanno risparmiato agli sviluppatori molte ore di tedioso lavoro.
 


Per l'uso di sarge in ambito desktop (ma non solo) sono molto utili i [[backport]]:
== Gestire le proprie patch con quilt ==


* [http://backports.org/ Debian Backports]
I programmi ''patch'' e ''diff'' risultano essere molto utili e funzionali per lo sviluppo del kernel. Ma dopo un certo periodo di utilizzo, molti si stancano di questo modo si procedere nello sviluppo e cercano altra strade che non coinvolgano le noiose attivit� di pacthing e merging. Fortunatamente, alcuni sviluppatori del kernel hanno realizzato un programma chiamato ''quilt'' che gestisce il processo di manipolazione delle patch in modo molto pi� semplice.


=== Stabile: Debian Etch ===
L'idea alla base di ''quilt'' discende da un insieme di script da Andrew Morton, realizzati originariamente per gestire il codice del ''memory management subsystem'' e, in seguito, utilizzati per l'intero kernel. I suoi script erano legati molto strettamente al processo di lavoro di sviluppo, ma l'idea sottostante era molto potente.
Andreas Gruenbacher ha quindi ripreso questa idea creando ''quilt''.


  ## Debian Stable (etch)
L'idea principale sottostante ''quilt'' � di lavorare con una versione ''pulita'' del kernel alla quale aggiungere un insieme di patch. E&grave; possibile inserire e togliere diverse patch dal sorgente e mantenere una lista delle patch in modo molto semplice.
  deb http://ftp.it.debian.org/debian/ stable main contrib non-free
  #deb-src http://ftp.it.debian.org/debian/ stable main contrib non-free
  ## Aggiornamenti della sicurezza
  deb http://security.debian.org/ stable/updates main contrib
  #deb-src http://security.debian.org/ stable/updates main contrib


=== Testing: Debian Lenny ===
1. Per iniziare, creiamo una directory contenente il sorgente del kernel:
<pre>
$ tar -zxf linux-2.6.19.tar.gz
$ ls
linux-2.6.19/
</pre>


  ## Debian Stable (etch)
2. Spostiamoci in tale directory:
  deb http://ftp.it.debian.org/debian/ testing main contrib non-free
<pre>
  #deb-src http://ftp.it.debian.org/debian/ testing main contrib non-free
$ cd linux-2.6.19
</pre>
  ## Aggiornamenti della sicurezza
  deb http://security.debian.org/ testing/updates main contrib
  #deb-src http://security.debian.org/ testing/updates main contrib


=== Unstable: Debian Sid ===
3. Creiamo una directory ''patches'' che conterr� tutte le nostre patch:
<pre>
$ mkdir patches
</pre>


  ## Debian Unstable (sid)
4. Tramite ''quilt'' creiamo una nuova patch chiamata ''patch1'':
  deb http://ftp.it.debian.org/debian/ unstable main contrib non-free
<pre>
  #deb-src http://ftp.it.debian.org/debian/ unstable main contrib non-free
$ quilt new patch1
Patch patches/patch1 is now on top
</pre>


Per '''Sid''' non c'� il repository per la sicurezza dato che eventuali falle vengono corrette semplicemente con l'aggiornamento del pacchetto incriminato.
5. ''quilt'' necessita di sapere quali file saranno modificati da questa patch. Per fare questo, utilizziamo il comando ''add'':
<pre>
$ quilt add Makefile
File Makefile added to patch patches/patch1
</pre>


== Lista repository non ufficiali ==
6. Editiamo il ''Makefile'' e modifichiamo la linea EXTRAVERSION, salvando poi il file. Alla fine, aggiorniamo la patch tramite ''quilt'':
Per una lista dei repository non ufficiali pi� diffusi vedere: [[Repository non ufficiali]].


== La Struttura dei repository ==
<pre>
Un repository � suddivisibile, grossomodo, in due sezioni:
$ quilt refresh
* '''dists''' in questo ramo sono contenuti i file di controllo, che permettono il funzionamento del sistema di pacchettizzazione. Infatti sono presenti i file che descrivono i pacchetti presenti nell'archivio (divisi per la release di appartenenza);
Refreshed patch patches/patch1
* '''doc''' raccoglie la documentazione di base per Debian (segnalazioni di Bug, Faq, il Contratto Sociale ed altro)
</pre>
* '''indices''' contiene l'indice di tutti i file contenuti in tutti i pacchetti. Queste informazioni sono usate da [[Apt-file: ricerca all'interno dei pacchetti|<tt>apt-file</tt>]].
* '''non-US''' a causa di problemi legali dovuti al divieto di esportazione di matariale per la difesa (tra cui materiale crittografici, utilizzati anche in PGP e SSH). Per ovviare a questi problemi, i pacchetti sono stati posti in una sezione a parte, la cui distribuzione � legata a server non Statunitensi.
* '''pool''' questo � l'archivio vero e proprio, dove sono contenuti i pacchetti, raggruppati per lettera iniziale;
* '''project''' contiene materiale per sviluppatori. Degne di nota la direcotory experimetal, che contiene i pacchetti in fase di sviluppo e perfezionamento;<br/>
* '''tools''' contiene degli strumenti Dos per la creazione di dischetti di boot, partizionamento e lancio di Linux.


== La Suddivisione del repository ==
Il file ''patches/patch1'' conterr� una patch con tutti i cambiamenti appena fatti:
Navigando un po' tra gli archivi Debian, si nota subito una particolare suddivisione: i repository, infatti, sono divisi in '''main''', '''contrib''' e '''non-free''', nel modo seguente:
<pre>
* '''main''' � la sezione principale, che contiene il 90% dei pacchetti presenti in Debian
$ cat patches/patch1
* '''contrib''' raccoglie i pacchetti coerenti con la DFSG5.6, ma che dipendono da pacchetti che non la rispettano
Index: linux-2.6.19/Makefile
* '''non-free''' contiene dei pacchetti che possiedono delle limitazioni nella distribuzione (ad esempio perch� non utilizzabili in ambito commerciale o perch� dipendenti da applicazioni o pacchetti che non rispettano la Debian Free Software Guideline)
===================================================================
--- linux-2.6.19.orig/Makefile
+++ linux-2.6.19/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
-EXTRAVERSION =
+EXTRAVERSION = -dirty
NAME=Crazed Snow-Weasel
# *DOCUMENTATION*
</pre>


== Sources.list ==
Ora � possibile continuare a lavorare su una patch, o crearne una nuova in testa a quella attuale.
=== Il ruolo fondamentale ===
Ad esempio, se sono state create tre diverse patch ''patch1'', ''patch2'' e ''patch3'', esse saranno applicate una sopra l'altra.
Il file '''/etc/apt/sources.list''' � forse il pi� importante file di configurazione del sistema di gestione dei pacchetti Debian. Esso, infatti, contiene l'elenco e gli indirizzi dei repository a cui apt accede.
Per vedere la lista delle patch attualmente applicate:
<pre>
$ quilt series -v
+ patches/patch1
+ patches/patch2
= patches/patch3
</pre>


=== Ordine di Inserimento ===
L'output mostra che tutte e tre le patch sono state applicate e che quella corrente � la ''patch3''.
� importante inserire i repository con un giusto ordine: i primi in elenco, infatti, sono i pi� importanti (o favoriti). Per migliorare le performance, � consigliabile ordinarli per velocit� (Es. prima il cdrom, poi la rete locale, poi internet, ...).
Al rilascio di una nuova versione del kernel, se si vuole portare i cambiamenti effettuati sulle versione recedente anche sulla nuova versione, � possibile utilizzare ''quilt'' secondo i seguenti passi:


=== Sintassi ===
1. Togliere le patch attualmente applicate al sorgente
Ogni riga che descrive un repository ha una ben determinata sintassi:
<pre>
<pre>
deb uri distribution [component..]
$ quilt pop -a
Removing patch patches/patch3
Restoring drivers/usb/Makefile
Removing patch patches/patch2
Restoring drivers/Makefile
Removing patch patches/patch1
Restoring Makefile
No patches applied
</pre>
</pre>


Analizziamo i singoli componenti:
2. Utilizzando la patch ufficiale da ''kernel.org'' aggiornare la vecchia versione del kernel:
* '''deb o deb-src''' serve ad indicare se il repository indicato contiene pacchetti binari o pacchetti sorgenti (se li contiene entrambi, � necessario specificarlo usando due righe diverse).
<pre>
* '''uri''' indica l'indirizzo a cui � possibile trovare il repository; � possibile scegliere tra i seguenti metodi di accesso ai pacchetti:
$ patch -p1 < ../patch-2.6.20
** '''file''' permette di inserire un repository presente sull'Hard Disk del computer;
$ cd ..
** '''cdrom''' permette di inserire un repository presente su un cd-rom;
$ mv linux-2.6.19 linux-2.6.20
** '''http''' permette di accedere ad un repository tramite il protocollo http (se � impostata una variabile di ambiente '''http_proxy''' col formato '''http://server:port/''' verranno usate queste opzioni per accedere al repository; in caso di necessit� di autenticazione, � possibile specificare l'inidirizzo del proxy, nella variabile d'ambiente '''http_proxy''', nel seguente modo: '''http://user:pass@server:port/''', anche se risulta non essere un modo sicuro di autenticazione);
</pre>
** '''ftp''' permette di accedere ad un repository tramite il protocollo ftp; � possibile specificare un proxy nell stesso modo indicato per http al punto precedente, sostituendo alla variabile '''http_proxy''' '''ftp_proxy''';
** '''copy''' � idendico a file, ma i file utilizzati vengono salvati nella cache di apt; utile nel caso di supporti removibili quali Usb-drive, Floppy, Zip, ...;
3. A questo punto, tramite ''quitl'' applicare nuovamente le patch sul nuovo sorgente:
** '''rsh, ssh''' permette di accedere ad un repository tramite il protocollo ssh. Non � possibile, per�, effettuare alcuna autenticazione interativa, ma solo tramite lo scambio di chiavi RSA.
<pre>
* '''distribution''' indica la [[La struttura della Distribuzione|distribuzione (o release)]] utilizzata... � possibile usare il nome in codice (sarge, etch, sid) o il nome generico (stable, testing, unstable);
$ quilt push
*'''component''' indica la sezione (non-free, main, contrib...) del repository da inserire; sono possibili scelte multiple.
Applying patch patches/patch1
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- rejects in file Makefile
Patch patches/patch1 does not apply (enforce with -f)
</pre>


=== Alcuni esempi ===
4. Come risultato, le patch non si applicano immediatamente senza problemi. E&grave; possibile forzare l'applicazione della patch e poi procedere alle correzioni necessarie:
Non c'� niente di meglio, per capire la sintassi del file sources.list, si un po' di esempi.
<pre>
$ quilt push -f
Applying patch patches/patch1
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
Applied patch patches/patch1 (forced; needs refresh)
$ vim Makefile.rej Makefile
</pre>


I repository ufficiali (binari e sorgenti) presi da un mirror italiano:
5. Dopo aver applicato manualmente la patch, aggiornare la patch:
<pre>
<pre>
deb http://ftp.it.debian.org/debian/ stable main non-free contrib
$ quilt refresh
deb-src http://ftp.it.debian.org/debian/ stable main non-free contrib
Refreshed patch patches/patch1
</pre>
</pre>


Il repository di apt-build (Rif. 7.1 Pag. [*]):
6. Procedere all'applicazione delle altre patch:
<pre>
<pre>
deb file:/var/cache/apt-build/repository apt-build main
$ quilt push
Applying patch patches/patch2
patching file drivers/Makefile
Now at patch patches/patch2
$ quilt push
Applying patch patches/patch3
patching file drivers/usb/Makefile
Now at patch patches/patch3
</pre>
</pre>


Un repository 'artigianale' accessibile tramite un webserver:
 
''quilt'' ha anche delle opzioni che permettono di inviare automaticamente le nuove patch ad un gruppo di persone o ad una mailing list, di eliminare specifiche patch all'interno della serie, di ricercare una specifica patch all'interno della serie e molte altre utili opzioni.
 
''quilt'' � fortemente raccomandato per qualsiasi attivit� di sviluppo del kernel, anche per tenere traccia di poche patch, invece di usare i pi� ostici ''diff'' e ''patch''. E&grave; decisamente pi� semplice � consente di risparmiare parecchio tempo e sforzi.
 
Come nota personale, non raccomander� mai abbastanza l'utilizzo di questo tool, poich� lo utilizzo tutti i giorni per gestire centinaia di patch in diversi rami di sviluppo.
Esso � anche usato da numerose distribuzioni Linux per gestire il proprio kernel e pu� contare su una comunit� di sviluppo entusiasta e reattiva.
 
== git ==
 
''git'' � uno strumento di controllo del codice sorgente originariamente scritto da Linus Torvalds quando stava cercando un nuovo sistema di gestione del codice per il kernel di Linux.
 
&Egrave; un sistema distribuito che differisce dai sistemi tradizionali di gestione del codice (come ad esempio CVS) nel fatto che non � necessario essere connessi al server per effettuare un commit sul repository.
 
''git'' � uno dei pi� potenti, flessibili e veloci sistemi di gestione del codice sorgente attualmente disponibili, e ha alle spalle un team di sviluppo molto attivo.
La pagina principale di ''git'' � ''http://git.or.cz/''.
Si raccomanda ad ogni nuovo utente di seguire i tutorial pubblicati al fine di familiarizzare con la modalit� di funzionamento di git, in modo da poterlo utilizzare propriamente.
 
Il kernel di Linux � sviluppato utilizzando ''git'', e le ultime versioni possono essere trovate all'indirizzo ''http://www.kernel.org/git/'' insieme ad una vasta lista di altri repository git.
 
Non � necessario utilizzare ''git'' per sviluppare il kernel di Linux, ma � molto utile per tenere traccia del bug rilevati.
Se doveste riportare un bug agli sviluppatori del kernel, essi potranno richiedevi di utilizzare ''git bisect'' al fine di identificare l'esatta modifica che ha causato il bug. In questo caso, potete seguite le indicazioni sulla documentazione di ''git'' per capire come procedere.
 
== ketchup ==
 
''ketchup'' � uno strumento molto comodo utilizzato per aggiornare una versione del kernel o per passare da una versione all'altra del codice sorgente.
 
Esso offre la possibilit� di:
* Trovare l'ultima versione del kernel, scaricarla e decomprimerla.
* Aggiornate una versione attualmente installata del codice sorgente del kernel, applicando le patch necessarie.
* Gestire i diversi rami di sviluppo del kernel, incluse le versioni -mm e -stable
* Scaricare qualsiasi patch o archivio tar necessario per l'aggiornamento, se non gi� presenti sulla macchina locale.
* Controllare la firma GPG dell'archivio e delle patch per verificarne l'integrit�.
 
''ketchup'' si trova all'indirizzo ''http://www.selenic.com/ketchup/'' insieme a molta documentazione presente nel wiki ''http://www.selenic.com/ketchup/wiki/''.
 
Di seguito un esempio che illustra quanto sia semplice utilizzare ''ketchup'' per fare il download di una specifica versione del kernel e '''per passare ad un'altra versione''' con un numero minimo di comandi.'''VERIFICARE LA TRADUZIONE DELLA PARTE IN GRASSETTO [...and then have it switch the directoryto another kernel version...]'''
 
Per scaricare il sorgente del kernel 2.6.16.24 in una directory, e rinominare la directory perch� abbia lo stesso nome della versione del kernel, utilizzare il seguente comando:
 
<pre>
<pre>
deb http://repos.debianizzati.org ./
$ mkdir foo
$ cd foo
$ ketchup -r 2.6.16.24
None -> 2.6.16.24
Unpacking linux-2.6.17.tar.bz2
Applying patch-2.6.17.bz2 -R
Applying patch-2.6.16.24.bz2
Current directory renamed to /home/gregkh/linux/linux-2.6.16.24
</pre>
</pre>


Un repository situato nella home dell'utente maxer, creato con <code>dpkg-scanpackages</code>:
Ora, per aggiornare il sorgente affinch� contenga l'ultimo rilascio stabile, digitare:
<pre>
<pre>
deb file:/home/maxer/repos ./
$ ketchup -r 2.6
2.6.16.24 -> 2.6.17.11
Applying patch-2.6.16.24.bz2 -R
Applying patch-2.6.17.bz2
Downloading patch-2.6.17.11.bz2
--22:21:14-- http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.11.bz2
=> `/home/greg/.ketchup/patch-2.6.17.11.bz2.partial'
Resolving www.kernel.org... 204.152.191.37, 204.152.191.5
Connecting to www.kernel.org|204.152.191.37|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 36,809 (36K) [application/x-bzip2]
100%[====================================>] 36,809 93.32K/s
22:21:14 (92.87 KB/s) - `/home/greg/.ketchup/patch-2.6.17.11.bz2.partial'saved [36809/36809]
Downloading patch-2.6.17.11.bz2.sign
--22:21:14-- http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.11.bz2.sign
=> `/home/greg/.ketchup/patch-2.6.17.11.bz2.sign.partial'
Resolving www.kernel.org... 204.152.191.37, 204.152.191.5
Connecting to www.kernel.org|204.152.191.37|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 248 [application/pgp-signature]
100%[====================================>] 248 --.--K/s
22:21:14 (21.50 MB/s) - `/home/greg/.ketchup/patch-2.6.17.11.bz2.sign.
partial' saved [248/248]
Verifying signature...
gpg: Signature made Wed Aug 23 15:01:04 2006 PDT using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key >
ftpadmin@kernel.org<"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
Applying patch-2.6.17.11.bz2
Current directory renamed to /home/greg/linux/tmp/x/linux-2.6.17.11
</pre>
</pre>


Per altri repository vedere: [[#Lista repository ufficiali debian|Lista repository ufficiali debian]] e [[Repository non ufficiali]].


----  
Questo esempio mostra come ''ketchup'' determini in modo automatico che la nuova versione stabile del kernel � la 2.6.17.11 ed effettua il download delle patch necessarie per aggiornare il sorgente.
[[User:MaXeR|MaXeR]]
 
[[Categoria:Apt]]
L'uso di ''ketchup'' � fortemente raccomandato per il download di qualsiasi sorgente del kernel di Linux. Esso si prende in carico il lavoro relativo a trovare le patch necessarie e ad applicarle automaticamente nel modo corretto, dopo averne controllato l'autenticit� tramite la firma digitale.
[[Categoria:Repository]]
 
L'uso combinato di ''ketchup'' e ''quilt'' permette di avere tutto ci� che serve per gestire il kernel di Linux e per soddisfare le esigenze degli sviluppatori.
 
----
This is an indipendent translation of the book [http://www.kroah.com/lkn/ Linux Kernel in a Nutshell] by [http://www.kroah.com/log/ Greg Kroah-Hartman]. This translation (like the original work) is available under the terms of [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5].
----
 
[[Categoria:Kernel]]
Perseus
21

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/14878"

Menu di navigazione