15.4.1. Imparare a creare pacchetti
Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.
Un pacchetto Debian deve rispettare delle regole ben precise presenti nelle Debian policy ed ogni maintainer di pacchetti deve conoscerle. Non c'è l'obbligo di conoscerle a memoria, ma è importante sapere che esistono e che si possono consultare ogni volta che si presenta una scelta alternativa non banale. Ogni maintainer Debian ha fatto degli errori dovuto al fatto che non conosceva una regola, ma questo non è un grosso problema finchè l'errore verrà risolto quando un utente lo segnalerà con un bug report (cosa che normalmente accadere molto presto grazie agli utenti esperti). Il campo
Standards-Version in
debian/control specifica la versione delle Debian policy a cui un pacchetto è conforme. I manutentori dovrebbero conformarsi all'ultima versione delle Debian policy.
Debian non è una semplice raccolta di singoli pacchetti. Il lavoro di pacchettizzazione di ognuno è parte di un progetto collettivo; essere uno sviluppatore Debian implica conoscere come opera, nel suo complesso, il progetto Debian. Ogni sviluppatore, prima o poi, interagisce con gli altri. La guida di riferimento per lo sviluppatore Debian (nel pacchetto
developers-reference) riassume ciò che ogni sviluppatore deve conoscere per interagire nel miglior modo possibile con i vari team all'interno del progetto, e come usufruire dei possibili vantaggi dati delle risorse disponibili. Questo documento elenca anche una serie di doveri a cui uno sviluppatore dovrebbe adempiere.
Molti strumenti aiutano i maintainer di pacchetti nel loro lavoro. In questa sezione verranno descritti brevemente, tralasciando tutti i dettagli, dal momento che tutti hanno una propria documentazione completa.
Il pacchetto devscripts contiene molti programmi che aiutano in una vasta gamma del lavoro dello sviluppatore Debian:
debuild permette di generare un pacchetto (con dpkg-buildpackage) ed eseguire lintian per verificarne la conformità con le policy di Debian.
debclean pulisce un pacchetto sorgente dopo che è stato generato un pacchetto binario.
dch permette di modificare velocemente il file debian/changelog nel sorgente del pacchetto.
uscan verifica se è stata rilasciata una nuova versione del software dall'autore originale; questo richiede il file debian/watch con una descrizione delle posizioni delle varie versioni.
debi permette di installare (con dpkg -i) il pacchetto Debian che è stato appena generato senza bisogno di digitare il suo nome completo e il percorso.
In modo simile, debc consente la scansione dei contenuti del pacchetto generato di recente (con dpkg -c), senza la necessità di digitare il suo nome completo e il percorso.
bts controls the bug tracking system from the command line; this program automatically generates the appropriate emails.
debrelease carica il pacchetto generato di recente in un server remoto, senza la necessità di digitare il nome completo e il percorso del relativo file .changes.
debsign firma i file *.dsc e *.changes.
uupdate automatizza la creazione di una nuova versione del pacchetto, appena è rilasciata una nuova versione del software originale.
All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: ~/.devscripts.
15.4.1.3.2. debhelper e dh-make
Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).
Lo script dh_make (nel pacchetto dh-make) crea i file necessari per la generazione di un pacchetto Debian, in una directory contenente i sorgenti di un software. Come si può immaginare dal nome del programma, i file generati utilizzano debhelper in maniera predefinita.
Questo strumento è uno dei più importanti: si occupa di verificare i pacchetti Debian. Si basa su una vasta gamma di test creati dalla policy di Debian, e rileva in modo rapido e automatico molti errori che possono essere risolti prima che i pacchetti vengano rilasciati.
Questo strumento lo si deve considerare solamente come un aiuto e può capitare che a volte si comporti in modo errato (per esempio, poiché le policy di Debian cambiano nel corso del tempo, lintian a volte può essere obsoleto). Inoltre non è molto dettagliato: se non si riceve alcun errore da Lintian non di deve interpretare questo comportamento come la prova che il pacchetto sia perfetto ma che, al massimo, non contiene gli errori più comuni.
Questo è un altro importante strumento: automatizza l'installazione, l'aggiornamento, la rimozione e l'eliminazione completa di un pacchetto (in un ambiente isolato), e controlla che nessuna di queste operazioni dia luogo ad un errore. Può essere d'aiuto nel rilevare le dipendenze mancanti, inoltre rileva anche quando i file vengono erroneamente lasciati dopo che il pacchetto è stato copmletamente eliminato.
autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.
reprotest compila lo stesso codice sorgente due volte in ambienti diversi, e poi controlla i binari prodotti da ogni build alla ricerca di differenze. Se ne vengono trovate, diffoscope (se non disponibile, diff) verrà usato per visualizzarle in dettaglio per un'analisi successiva.
15.4.1.3.7. dupload e dput
The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.
15.4.1.3.8. git-buildpackage and dgit
The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into
Git (
CULTURA Git) onto a Gitlab instance called
salsa.debian.org.
To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.
One of the most famous packages is git-buildpackage. An alternative is dgit. Of course it is still possible to use neither of those.
Below is an example for a ~/.gbp.conf configuration file
[DEFAULT]
builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL"
pristine-tar = true
[buildpackage]
sign-tags = true
keyid = XXXX
postbuild = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64
export-dir = /tmp/build-area/
notify = off
[import-orig]
filter-pristine-tar = true
sign-tags = true
[pq]
drop = true
Building the package is then as easy as running gbp buildpackage in the Git tree. It will start a package build in a Debian Bullseye chroot using sbuild. When the build succeeds, the created files are checked running the autopkgtest-testsuite (if defined). All the various options are explained in gbp.conf(5) and /etc/git-buildpackage/gbp.conf.
All the tools mentioned so far have been included in the continuous integration (CI) process in the
salsa.debian.org instance as well:
15.4.2. Processo di accettazione
Diventare uno sviluppatore Debian non è una semplice questione amministrativa. Il processo è costituito da diverse fasi, ed è tanto un'iniziazione quanto un processo di selezione. In ogni caso, l'intero processo è formalizzato e ben documentato, in modo che chiunque spuò monitorarne l'avanzamento di stato sul sito web dedicato al processo per il nuovo membro.
Tutti i candidati sono tenuti ad avere almeno una conoscenza di base della lingua inglese. Questo è necessario a tutti i livelli: per le comunicazioni iniziali con l'esaminatore, naturalmente, ma anche più avanti, dal momento che l'inglese è la lingua preferita per la maggior parte della documentazione, anche gli utilizzatori del pacchetto comunicheranno in inglese per la segnalazione di bug e si aspetteranno delle risposte in inglese.
Altri prerequisiti dipendono dalla motivazione. Diventare uno sviluppatore Debian è un processo che ha senso solo se il candidato sa che l'interesse per Debian durerà per molti mesi. Il processo di accettazione può durare diversi mesi ed ha bisogno di sviluppatori Debian a lungo termine, ogni pacchetto ha bisogno di manutenzione permanente, e non solo un caricamento iniziale.
Il primo (vero) passo consiste nel trovare uno sponsor o un sostenitore, il che significa uno sviluppatore ufficiale disposto a dichiarare che crede che accettare X sarebbe una buona cosa per Debian. Ciò implica in genere che il candidato sia già attivo all'interno della comunità e che il suo lavoro sia stato apprezzato. Se il candidato è timido e il suo lavoro non viene elogiato pubblicamente, può cercare di convincere uno sviluppatore Debian a sostenerlo, mostrandogli il suo lavoro in privato.
Al tempo stesso, il candidato deve generare una coppia, pubblica/privata, di chiavi RSA con GnuPG, che dovrebbe essere firmata da almeno due sviluppatore ufficiale Debian. La firma autentica il nome della chiave. In effetti, durante un key signing party, ogni partecipante deve mostrare un documento di identità ufficiale (solitamente una carta di identità o un passaporto) insieme all'identificativo della chiave. Questo passaggio conferma il legame tra la persona e la chiave. Questa firma richiede pertanto un riscontro nella vita reale. Se non si è ancora incontrato alcun sviluppatore Debian in una conferenza pubblica sul software libero, si possono cercare gli sviluppatori che vivono nelle vicinanze utilizzando l'elenco alla seguente pagina web come punto di partenza.
Una volta che la registrazione sul sito nm.debian.org è stata convalidata dal sostenitore, al candidato viene assegnato un Application Manager. Da quel portale, l'application manager guiderà poi il processo attraverso diversi passaggi e controlli predefiniti.
La prima verifica è un controllo d'identità. Se si possiede già una chiave firmata da due sviluppatori di Debian, questo passaggio è semplice; altrimenti, l'application manager cercherà di guidare il candidato alla ricerca di sviluppatori Debian nelle vicinanze per organizzare un incontro e firmare la chiave.
15.4.2.3. Accettare i principi
Queste formalità amministrative sono seguite da considerazioni filosofiche. Il punto è fare in modo che il candidato capisca e accetti il contratto sociale e i principi alla base del Software Libero. Partecipare a Debian è possibile solo se si condividono i valori che uniscono gli attuali sviluppatori, espressi nei testi dei fondamentali (e riassunti in
Capitolo 1, Il Progetto Debian).
Inoltre, ogni candidato che desidera aderire a Debian è tenuto a conoscere il funzionamento del progetto, e come interagire in modo appropriato per risolvere i problemi che, senza dubbio, si incontreranno col passare del tempo. Tutte queste informazioni sono generalmente documentate nei manuali rivolti ai nuovi maintainer e nella guida di riferimento per lo sviluppatore Debian. Una lettura attenta di questo documento dovrebbe essere sufficiente per rispondere alle domande dell'esaminatore. Se le risposte non sono soddisfacenti, il candidato sarà informato. Quindi, dovrà leggere (nuovamente) la relativa documentazione prima di riprovare. Nei casi in cui la documentazione esistente non contenesse la risposta appropriata per la domanda, il candidato di solito può trovare una risposta, facendo un po' di esperienza pratica in Debian, oppure discutendone con altri sviluppatori Debian. Questo meccanismo garantisce che i candidati vengano coinvolti un po' in Debian prima di diventare parte integrante del progetto. Si tratta di una scelta intenzionale, con la quale i candidati che alla fine aderiranno al progetto sono integrati come un altro pezzo di un puzzle infinitamente espandibile.
Questo passaggio è generalmente conosciuto come Philosophy & Procedures (P&P in breve) nel gergo degli sviluppatori coinvolti nel processo per i nuovi membri.
15.4.2.4. Verifica delle capacità
Ogni domanda per diventare uno sviluppatore ufficiale Debian deve essere giustificata. Per diventare un membro del progetto è necessario dimostrare di meritare tale stato e che lo stato di membro, semplifichi il contributo del candidato allo sviluppo di Debian. La giustificazione più comune è che sia concesso lo status di sviluppatore Debian perché facilita la manutenzione di un pacchetto Debian, ma non è l'unico motivo. Alcuni sviluppatori aderiscono al progetto per contribuire al porting di una specifica architettura, altri vogliono migliorare la documentazione, e così via.
Questo passaggio rappresenta l'occasione per il candidato di indicare che cosa intende fare nell'ambito del progetto Debian e di mostrare ciò che ha già fatto in tal senso. Debian è un progetto pragmatico e dire qualcosa che non è sufficiente, se non si compiono le azioni vengono annunciate. Generalmente, quando il ruolo previsto all'interno del progetto è legato alla manutenzione dei pacchetti, una prima versione del potenziale pacchetto dovrà essere convalidata tecnicamente e caricata sui server di Debian da uno sponsor tra gli sviluppatori Debian.
Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.
Questo passaggio è noto come il passaggio Tasks & Skills (T&S abbreviato) nel gergo degli esaminatori.
15.4.2.5. Approvazione finale
Nell'ultima fase, l'intero processo è revisionato da un DAM (Debian Account Manager). Il DAM riesaminerà tutte le informazioni sul candidato che l'esaminatore ha raccolto e deciderà se creare o meno un account nei server Debian. Nei casi in cui sono richieste ulteriori informazioni, la creazione dell'account può essere rinviata. I rifiuti sono piuttosto rari se l'esaminatore fa un buon lavoro seguendo in maniera corretta l'iter, ma a volte succede. In ogni caso il rifiuto non è permanente e il candidato è libero di riprovare in un secondo momento.
La decisione del DAM è autorevole e (quasi) senza appello, il che spiega perché le persone in questa posizione sono state spesso criticate in passato.
