Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as
Testing or even
Unstable — so that this new package works in their
Stable distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information.
15.1.1. Ottenere i sorgenti
Rebuilding a Debian package starts with getting its source code. The easiest way is to use the
apt-get source source-package-name
command. This command requires a
deb-src
line in the
/etc/apt/sources.list
file, and up-to-date index files (i.e.
apt-get update
). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see
Sezione 6.1, «Compilazione del file sources.list
»). Note however, that you will be downloading the source packages from the Debian version mentioned in the
deb-src
line. If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions
*.dsc
— for
Debian Source Control —
*.tar.comp
, and sometimes
*.diff.gz
or
*.debian.tar.comp
—
comp taking one value among
gz
,
bz2
or
xz
depending on the compression tool in use), then run the
dpkg-source -x file.dsc
command. If the
*.dsc
file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the
dget URL
command. This command (which can be found in the
devscripts package) fetches the
*.dsc
file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it extracts the source package (unless the
-d
or
--download-only
option is used).
15.1.2. Apportare modifiche
The source of the package is now available in a directory named after the source package and its version (for instance, samba-4.1.17+dfsg); this is where we'll work on our local changes.
The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.1.17+dfsg-2
, we can create version 2:4.1.17+dfsg-2falcot1
, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch
command (Debian CHangelog) from the devscripts package, with an command such as dch --local falcot
. This invokes a text editor (sensible-editor
— this should be your favorite editor if it is mentioned in the VISUAL
or EDITOR
environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that dch
really did change the debian/changelog
file.
When a change in build options is required, the changes need to be made in debian/rules
, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …
) or the actual build ($(MAKE) …
or make …
) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh
, you might need to add an override for the dh_auto_configure
or dh_auto_build
commands (see their respective manual pages for explanations on how to achieve this).
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 i campi Build-Depends
non sono stati aggiornati 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. O peggio ancora, 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.
Il più delle volte, gli sviluppatori Debian utilizzano un programma di alto livello come debuild
. Questo esegue dpkg-buildpackage
e richiama un programma che avvia molti controlli per convalidare le policy Debian del pacchetto generato. Questo script fa in modo che le variabili d'ambiente locali non «inquinino» la fase di generazione del pacchetto. Il comando debuild
è uno degli strumenti della suite devscripts, che condividono la stessa consistenza e configurazione, per rendere il compito più facile ai maintainer.