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 permette di controllare il sistema di tracciamento dei bug dalla riga di comando; inoltre, genera automaticamente le e-mail in maniera appropriata.
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.
Tutti i comandi menzionati sono documentati nelle loro rispettive pagine di manuale. Possono essere ulteriormente configurati per ogni utente nel file: ~/.devscripts.
15.4.1.3.2. debhelper e dh-make
Debhelper è un insieme di script che aiutano nella creazione di pacchetti conformi alle policy; questi script sono invocati da debian/rules. Debhelper è stato ampiamente adottato all'interno di Debian, come dimostra il fatto che è usato dalla maggior parte dei pacchetti ufficiali Debian. Tutti i comandi in esso contenuti hanno un prefisso dh_. Ognuno di essi è documentato in una pagina di manuale. I diversi livelli di compatibilità e le opzioni comuni sono descritti 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 esegue test sui pacchetti binari, utilizzando i test forniti nel pacchetto sorgente in debian/tests/. Diversi comandi permettono di creare facilmente ambienti di test virtuali o chroot.
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
I comandi dupload e dput permettono il caricamento di un pacchetto Debian su un server (anche remoto). Questo permette agli sviluppatori di pubblicare il proprio pacchetto sul server principale di Debian (ftp-master.debian.org) in modo che possa essere integrato nell'archivio e distribuito nei mirror. Questi comandi prendono il file .changes come parametro e deducono gli altri file pertinenti dal suo contenuto.
15.4.1.3.8. git-buildpackage e dgit
Negli anni il progetto ha usato diversi sistemi di controllo delle versioni per registrare gli sforzi di pacchettizzazione e il codice sorgente dei pacchetti o per permettere la manutenzione collaborativa dei pacchetti. Nel tentativo di unificare i sistemi e gli sforzi è stato infine deciso nel 2017 di spostare (quasi) tutti i sorgenti di pacchetti in
Git (
CULTURA Git), dentro un'istanza di Gitlab chiamata
salsa.debian.org.
Sono stati sviluppati degli strumenti per semplificare, agli sviluppatori di Debian, la pacchettizzazione tramite Git. Questi permettono non soltanto di registrare in Git i file di pacchettizzazione, ma anche di usare i repository Git (e la loro cronologia) per progetti software, inserire patch applicate ai sorgenti dei pacchetti dentro la cronologia di Git, mantenere le versioni del software per le distribuzioni, ecc.
Uno dei più famosi pacchetti è git-buildpackage. Un'alternativa è dgit. Naturalmente è sempre possibile non usare nessuno di questi.
Qiu sotto è presente un esempio per un file di configurazione ~/.gbp.conf
[DEFAULT]
builder = sbuild -d bookworm --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-bookworm-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 Bookworm 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.
Tutti gli strumenti menzionati fin'ora sono stati inclusi anche nel processo di Continuous Integration (CI - Integrazione continua) nell'istanza di
salsa.debian.org:
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 comprenda e accetti il contratto sociale ed i principi alla base del Software Libero. L'adesione a Debian è possibile solo se si condividono i valori che accomunano gli attuali sviluppatori, espressi nei testi fondanti (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.
Infine, l'esaminatore verifica le competenze tecniche (di pacchettizzazione) del candidato con un questionario dettagliato. Non sono ammesse risposte sbagliate, ma il tempo per rispondere è illimitato. Tutta la documentazione è disponibile e sono consentiti diversi tentativi, se le prime risposte non sono soddisfacenti. Questo passaggio non ha come obiettivo quello di discriminare i candidati, ma assicurarsi che i nuovi collaboratori abbiamo un minimo di conoscenza.
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.
