Capitolo 7. Controllare il pacchetto per errori

Indice

7.1. Modifiche sospette
7.2. Verifica dell'installazione di un pacchetto
7.3. Verifica degli script del manutentore di un pacchetto
7.4. Utilizzare lintian
7.5. Il comando debc
7.6. Il comando debdiff
7.7. Il comando interdiff
7.8. Il comando mc

È disponibile la riscrittura di questo tutorial, con contenuti aggiornati e con esempi più pratici, denominato Guide for Debian Maintainers. Si prega di utilizzare il nuovo tutorial come documento primario.

Ci sono alcune tecniche da sapere per controllare se un pacchetto ha degli errori prima di caricarlo negli archivi pubblici.

Effettuare dei test su altre macchine oltre a quella con cui si è sviluppato è una buona idea. Si deve inoltre fare attenzione agli avvisi ed agli errori per tutti i test che verranno qui descritti.

Se si trova un nuovo file di patch generato automaticamente, come debian-changes-* nella directory debian/patches dopo aver costruito un pacchetto Debian non-nativo nel formato 3.0 (quilt), è probabile che è stato cambiato qualche file per caso o che gli script di build hanno modificato il sorgente originale. Se è si tratta di un errore del genere, lo si risolva. Se è causato dallo script di build, si cerchi la causa principale del problema con dh-autoreconf come mostrato in Sezione 4.4.3, «Personalizzazione del file rules» o si cerchi di aggirare il problema con source/options come mostrato in Sezione 5.24, «source/options».

Bisogna verificare che il pacchetto si installi senza problemi. Il comando debi(1) aiuta a testare l'installazione di tutti i pacchetti binari generati.

$ sudo debi gentoo_0.9.12-1_i386.changes

Per prevenire eventuali problemi di installazione su sistemi diversi, bisogna assicurarsi che non ci siano file in conflitto con altri pacchetti esistenti utilizzando il file Contents-i386 scaricato dall'archivio Debian. Il comando apt-file può tornare utile a questo scopo. Se ci sono file che si sovrappongono, si prega di prendere delle misure per evitare l'insorgere del problema, rinominando il file, spostando il file in un pacchetto separato e configurarlo come dipendenza sui vari pacchetti che lo richiedono, utilizzando meccanismi alternativi (si veda update-alternatives(1)) che permettendo di coordinarsi con i manutentori degli altri pacchetti interessati o settano la voce Conflicts nel file debian/control.

Tutti gli script del manutentore (ad esempio i file, preinst, prerm, postinst, e postrm) sono difficili da scrivere correttamente a meno che non siano stati generati automaticamente dai programmi di debhelper. Si consiglia pertanto di non utilizzarli se non si ha sufficiente esperienza come manutentore (si veda Sezione 5.18, «{pre,post}{inst,rm}»).

Se il pacchetto utilizza questi particolari script del manutentore, ci si assicuri di effettuare delle prove non solo per l'operazione di install, ma anche per il remove, purge, e l'upgrade. Molti bug degli script del manutentore vengono fuori quando i pacchetti sono rimossi o viene applicato il purge. Si utilizzi il comando dpkg nel seguente modo per testarli:

$ sudo dpkg -r gentoo
$ sudo dpkg -P gentoo
$ sudo dpkg -i gentoo_version-revision_i386.deb

Questa operazione si dovrebbe effettuare con delle sequenze di questo tipo:

  • installazione della versione precedente (se necessaria).

  • aggiornamento dalla versione precedente.

  • ritorno alla versione precedente (opzionale).

  • applicazione del purge.

  • installazione del nuovo pacchetto.

  • rimozione del pacchetto.

  • reinstallazione del pacchetto.

  • applicazione del purge.

Se si sta creando il primo pacchetto, andrebbero creati dei pacchetti fittizi con diversi numeri di versione per testare il pacchetto originale in anticipo e prevenire problemi futuri.

Si tenga in mente che se il pacchetto è stato già rilasciato in Debian, le persone spesso effettueranno un aggiornamento a quest'ultimo a partire dall'ultima versione disponibile su Debian. Si ricordi di testare gli aggiornamenti anche a partire da questa versione.

Anche se il ritorno ad una versione precedente non è ufficialmente supportato, sarebbe buona abitudine supportarlo.

Si esegua lintian(1) sul file .changes. Il comando lintian esegue molti script di test alla ricerca dei più comuni errori di pacchettizzazione. [75]

$ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes

Ovviamente va rimpiazzato il nome con quello del file .changes generato per il pacchetto. I risultati del comando lintian vengono qui elencati di seguito:

  • E: errore; una violazione certa di una policy o un errore di pacchettizzazione.

  • W: attenzione; una possibile violazione di policy o un errore della pacchettizzazione.

  • I: informazione; un'informazione su alcuni aspetti della pacchettizzazione.

  • N: nota; un messaggio dettagliato per aiutare nell'analisi degli errori.

  • O: per sovrascrivere: il messaggio verrà sovrascritto dal file lintian-overrides, ma potrà essere visualizzato con l'opzione --show-overrides.

Quando vengono generati degli avvertimenti, si imposti il pacchetto in modo tale da evitarli o si verifichi che tali avvertimenti non siano indicativi di un errore. In quest'ultimo caso, si impostino i file lintian-overrides come descritto in Sezione 5.14, «{pacchetto.,source/}lintian-overrides».

Si noti che si può costruire il pacchetto con dpkg-buildpackage ed eseguire lintian su di esso in una sola volta con debuild(1) o con pdebuild(1).

Si possono elencare i file nel pacchetto binario Debian con il comando debc(1).

$ debc package.changes

Si può confrontare il contenuto dei file in due pacchetti sorgente Debian con il comando debdiff(1).

$ debdiff old-package.dsc new-package.dsc

Si possono anche confrontare le liste di file in due set di pacchetti binari Debian con il comando debdiff(1).

$ debdiff old-package.changes new-package.changes

Questi comandi sono utili per vedere cosa sia cambiato nei pacchetti sorgente, se un file sia stato spostato inavvertitamente o rimosso dai pacchetti, e se altri cambiamenti non intenzionali siano stati fatti durante l'aggiornamento dei pacchetti binari.

Si possono confrontare due file diff.gz con il comando interdiff(1). Questo è utile per verificare che il manutentore non abbia inavvertitamente fatto dei cambiamenti ai sorgenti durante il processo di aggiornamento dei pacchetti nel vecchio formato sorgente 1.0.

$ interdiff -z old-package.diff.gz new-package.diff.gz

Il nuovo formato sorgente 3.0 salva i cambiamenti in file di patch multipli come descritto in Sezione 5.25, «patches/*». È possibile tracciare i cambiamenti di ogni file debian/patches/* usando anche interdiff.

Molte delle operazioni di ispezione dei file possono essere rese più semplici utilizzando un gestore dei file come mc(1), che permette di navigare non solo il contenuto dei pacchetti in formato *.deb ma anche degli *.udeb, *.debian.tar.gz, *.diff.gz, e dei file *.orig.tar.gz.

Si faccia attenzione ad ulteriori file non necessari o vuoti, sia nel pacchetto binario che in quello sorgente. Spesso non vengono ripuliti correttamente; si aggiusti il file rules per riparare a questo problema.



[75] Non c'è bisogno di fornire l'opzione lintian -i -I --show-overrides se si è personalizzato il file /etc/devscripts.conf o il file ~/.devscripts come descritto in Sezione 6.3, «Il comando debuild».