Rigenerare un pacchetto binario può rendersi necessario per una serie di motivi. In alcuni casi, l'amministratore ha bisogno di una funzionalità presente nel software che richiede la compilazione dello stesso dai sorgenti, con una particolare opzione di compilazione; in altri casi, il software pacchettizzato per la versione di Debian installata non è abbastanza recente. In quest'ultimo caso, l'amministratore di solito costruisce un pacchetto più recente prendendolo da una nuova versione di Debian — come
Testing o addirittura
Unstable — in modo che questo nuovo pacchetto funzioni nella distribuzione
Stable; questa operazione è chiamata "backporting". Come al solito, prima di cominciare, è necessario controllare se qualcun altro ha già effettuato quest'attività — un rapido sguardo alle pagine del sistema di tracciamento dei pacchetti può darci le informazioni che cerchiamo.
15.1.1. Ottenere i sorgenti
La ricompilazione di un pacchetto Debian inizia ottenendo il codice sorgente. Il modo più semplice è usare il comando
apt-get source nome-del-pacchetto . Questo comando necessita di una riga
deb-src nel file
/etc/apt/sources.list ed un file degli indici aggiornato (cioè aver eseguito
apt-get update). Queste condizioni dovrebbero essere già soddisfatte se si sono seguite le istruzioni presenti nel capitolo della configurazione di APT (vedere
Sezione 6.1, «Compilazione del file sources.list»). Notare, tuttavia, che verranno scaricati i pacchetti di sorgenti della versione Debian indicata nella riga
deb-src.
Se si ha bisogno di un'altra versione, può essere necessario scaricarla manualmente da un mirror Debian o dal sito web. Questo comporta il recupero di due o tre file (con estensioni *.dsc — per Debian Source Control — *.tar.comp, e talvolta *.diff.gz o *.debian.tar.comp — comp assumendo un valore tra gz, bz2 o xz a seconda dello strumento di compressione in uso), quindi eseguire il comando dpkg-source -x file.dsc. Se il file *.dsc è direttamente accessibile ad un determinato URL, esiste un modo ancora più semplice per recuperarlo tutto, con il comando dget URL. Questo comando (che si trova nel pacchetto devscripts ) recupera il file *.dsc all'indirizzo indicato, poi ne analizza il contenuto e recupera automaticamente il file o i file a cui si fa riferimento. Una volta che tutto è stato scaricato, verifica l'integrità dei pacchetti sorgente scaricati usando dscverify ed estrae il pacchetto sorgente (a meno che non venga usata l'opzione -d o --download-only ). È necessario il portachiavi Debian, a meno che non venga fornita l'opzione -u.
15.1.2. Apportare modifiche
Usiamo il pacchetto samba come esempio.
$ apt source samba
Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 12.3 MB of source archives.
Get:1 http://security.debian.org/debian-security bullseye/updates/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B]
Get:2 http://security.debian.org/debian-security bullseye/updates/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB]
Get:3 http://security.debian.org/debian-security bullseye/updates/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB]
Fetched 12.3 MB in 3s (4,582 kB/s)
dpkg-source: info: extracting samba in samba-4.13.13+dfsg
dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
dpkg-source: info: applying [...]
Il sorgente del pacchetto è ora disponibile in una directory con il nome del pacchetto sorgente e della sua versione (samba-4.13.13+dfsg); è qui che lavoreremo alle nostre modifiche locali.
La prima cosa da fare è cambiare il numero di versione del pacchetto, in modo che i pacchetti ricreati possano essere distinti dai pacchetti originali forniti da Debian. Supponendo che la versione corrente sia la
2:4.13.13+dfsg-1~deb11u3, possiamo creare la versione
2:4.13.13+dfsg-1~deb11u3+falcot1, che indica chiaramente l'origine del pacchetto. In questo modo il numero di versione del pacchetto sarà superiore a quello fornito da Debian, così da essere installato come aggiornamento del pacchetto originale. Questa modifica si può effettuare con il comando
dch (
Debian CHangelog) dal pacchetto
devscripts.
$ cd 4.13.13+dfsg-1~deb11u3
$ dch --local +falcot
L'ultimo comando invoca un editor di testo (
sensible-editor — questo dovrebbe essere il vostro editor preferito se è menzionato nelle variabili d'ambiente
VISUAL o
EDITOR, altrimenti l'editor predefinito ) per consentire la documentazione delle differenze apportate da questa rielaborazione. Questo editor ci mostra che
dch ha davvero cambiato il file
debian/changelog.
Quando è necessario cambiare le opzioni di compilazione, le modifiche devono essere apportate in debian/rules, che guida le fasi del processo di compilazione del pacchetto. Nei casi più semplici, le righe che riguardano la configurazione iniziale (./configure ...) o la compilazione vera e propria ($(MAKE) ... o make ... o cmake ... o ...) sono facili da individuare. Se questi comandi non sono chiamati esplicitamente, probabilmente sono una conseguenza di un altro comando esplicito, nel qual caso fare riferimento alla loro documentazione per comprendere come cambiare il comportamento predefinito. Con i pacchetti che usano dh, potrebbe essere necessario aggiungere una sovrascrittura per i comandi dh_auto_configure o dh_auto_build (vedere le rispettive pagine di manuale e debhelper(7) per le spiegazioni su come ottenere tale risultato).
A seconda delle modifiche locali apportate ai pacchetti, può essere richiesto un aggiornamento anche nel file debian/control, che contiene una descrizione dei pacchetti generati. In particolare, questo file contiene le righe Build-Depends che permettono di controllare la lista delle dipendenze che devono essere soddisfatte nel momento della generazione del pacchetto. Queste spesso si riferiscono alle versioni dei pacchetti contenuti nella distribuzione da cui proviene il pacchetto sorgente, ma che potrebbero non essere disponibili nella distribuzione utilizzata per la rigenerazione. Non esiste un modo automatico per determinare se una dipendenza è reale o è specificata solamente per garantire che la costruzione deve essere eseguita solamente con l'ultima versione di una libreria. Questo è l'unico modo possibile per forzare un autobuilder ad utilizzare una determinata versione del pacchetto durante la costruzione, ed è il motivo per cui i maintainer Debian spesso utilizzano le dipendenze per la compilazione con versioni specifiche.
Se si sa per certo che queste dipendenze per la compilazione sono troppo stringenti, si possono rendere meno rigide localmente. I file che documentano il modo predefinito di costruire il software, spesso chiamati INSTALL, aiuteranno a capire quali sono le dipendenze appropriate. Idealmente, tutte le dipendenze devono poter essere soddisfatte dalla distribuzione utilizzata per la rigenerazione del pacchetto, se non lo sono, si avvia un processo ricorsivo, per cui per i pacchetti indicati nel campo Build-Depends deve essere fatto un "backport" prima che il pacchetto in questione sia costruito. Alcuni pacchetti non necessitano di backporting, e possono essere installati così come sono durante il processo di creazione (un esempio degno di nota è debhelper). Si noti che il processo di backporting può rapidamente diventare complesso se non si è attenti. Pertanto, i backport dovrebbero essere ridotti al minimo indispensabile, quando possibile.
15.1.3. Iniziare la rigenerazione del pacchetto
Quando sono state apportate tutte le modifiche necessarie ai sorgenti, si può iniziare a generare il pacchetto binario (il file .deb). L'intero processo è gestito dal comando dpkg-buildpackage.
Esempio 15.1. Rigenerazione di un pacchetto
$ dpkg-buildpackage -us -uc
[...]
Il comando precedente può fallire se il campo
Build-Depends non è stato aggiornato o se i relativi pacchetti non sono installati. In questo caso è possibile saltare questo controllo passando l'opzione
-d al comando
dpkg-buildpackage. Tuttavia, ignorando esplicitamente queste dipendenze, si corre il rischio che una fase successiva del processo di generazione fallisca. Ancora peggio, il pacchetto può sembrare generato correttamente, ma si comporta in modo anomalo: alcuni programmi disabilitano automaticamente alcune delle loro caratteristiche quando non è disponibile una libreria richiesta in fase di compilazione. La predetta opzione può essere comunque molto utile se si vuole creare solo un pacchetto sorgente, che dovrebbe essere passato ad ambienti di compilazione puliti, come descritto in
SGUARDO VELOCE Costruire pacchetti in ambienti chroot e virtuali.
Le altre opzioni usate nell'esempio precedente assicurano che né il file .dsc (-us) del pacchetto sorgente, né il file .changes (-uc) prodotto, vengano firmati con la chiave crittografica del compilatore dopo una corretta compilazione.
Il più delle volte, gli sviluppatori Debian utilizzano un programma di alto livello come debuild; esso esegue comunque dpkg-buildpackage salvo poi richiama un programma che avvia diversi controlli per convalidare il pacchetto generato rispetto alla politica Debian. Inoltre, questo script, evita che le variabili d'ambiente locali "inquinino" la fase di generazione del pacchetto. Il comando debuild è uno degli strumenti della suite devscripts, che condividono la stessa consistenza e configurazione per semplificare i compiti dei manutentori.
