Indice
debian/rules
debian/control
debian/changelog
debconf
.orig.tar.{gz,bz2,xz}
La qualità della distribuzione Debian è in gran parte dovuta alla Debian Policy, che definisce i requisiti di base espliciti che tutti i pacchetti Debian devono soddisfare. Ma vi è anche una storia condivisa di esperienza che va oltre la policy Debian, un accumulo di anni di esperienza nella pacchettizzazione. Molte persone di grande talento hanno creato grandi strumenti, strumenti che aiutano voi, i maintainer di Debian, a creare e mantenere ottimi pacchetti.
Questo capitolo fornisce alcune buone pratiche per gli sviluppatori Debian. Tutte le raccomandazioni sono solo tali, e non sono requisiti o policy. Questi sono solo alcuni spunti soggettivi, i consigli e i punti raccolti da sviluppatori Debian. Ci si senta liberi di scegliere quello che funziona meglio.
Le seguenti raccomandazioni si applicano al file
debian/rules
. Dal momento che il
debian/rules
controlla il processo di generazione e
seleziona i file da inglobare nel pacchetto (direttamente o indirettamente),
è normale che i maintainer del file spendano molto tempo su di esso.
L'idea nell'utilizzo degli script di aiuto in
debian/rules
è che essi hanno consentito ai maintainer
di usare e condividere la logica comune tra molti pacchetti. Si prenda per
esempio la questione dell'installazione delle voci di menu: è necessario
mettere il file in /usr/share/menu
(o
/usr/lib/menu
per gli eseguibili binari dei menufile,
se questo è necessario), e aggiungere i comandi agli script del maintainer
per registrare ed annullare la registrazione delle voci di menu. Dal momento
che questa è una cosa molto comune da fare con i pacchetti, perché ogni
maintainer dovrebbe riscrivere tutto questo da solo, a volte con bug?
Inoltre, supponendo che la cartella menu cambi, ogni pacchetto dovrebbe
essere cambiato.
Gli script di supporto si occupano di questi problemi. Supponendo che ci si attenga alle convenzioni previste dallo script di supporto, quest'ultimo si prende cura di tutti i dettagli. Cambiamenti nella policy possono essere effettuati nello script helper; successivamente i pacchetti avranno solo bisogno di essere ricompilati con la nuova versione dell'helper e nessuna ulteriore modifica.
Appendice A, Panoramica degli strumenti del Debian Maintainer contiene un paio di diversi script di supporto. Il
sistema di supporto più comune e migliore (a nostro parere) è debhelper
. I sistemi di supporto precedenti,
come debmake
, erano monolitici: non
si poteva scegliere quale parte dell'helper si riteneva utile, ma si doveva
usare l'helper per fare tutto. debhelper
, invece, è una serie di programmi
piccoli e separati dh_*. Per esempio,
dh_installman installa e comprime le pagine man,
dh_installmenu installa i file di menu, e così via. Così,
si offre sufficiente flessibilità per essere in grado di utilizzare i
piccoli script di aiuto, dove utile, in abbinamento con i comandi manuali in
debian/rules
.
Si può iniziare con debhelper
leggendo debhelper(1), e guardando gli esempi distribuiti
con il pacchetto. dh_make, dal pacchetto dh-make
(si consulti Sezione A.3.2, «dh-make
»),
può essere utilizzato per convertire un pacchetto sorgente normale in un
pacchetto debhelper
izzato. Questa
scorciatoia, però, non deve convincere che non è necessario preoccuparsi di
capire i singoli script dh_ *. Se si ha intenzione di
utilizzare uno script di supporto, ci si deve concedere il tempo necessario
per imparare ad usare quello script, per imparare le sue previsioni e il suo
comportamento.
Pacchetti grandi e complessi possono avere molti bug con cui ci si deve
rapportare. Se si corregge una serie di bug direttamente nel sorgente, e non
si sta attenti, può diventare difficile distinguere le varie patch che si
sono applicate. Può essere abbastanza caotico quando è necessario aggiornare
il pacchetto ad una nuova versione che integra alcune delle correzioni (ma
non tutte). Non si può prendere l'intero insieme di diff (ad esempio, da
.diff.gz
) e capire quali patch occorrono per tornare
indietro di una unità man mano che i bug vengono corretti nel sorgente
originale.
Fortunatamente, con il formato sorgente «3.0 (quilt)» è ora possibile
mantenere le patch separate senza dover modificare
debian/rules
per impostare un sistema di patch. Le
patch vengono memorizzate in debian/patches/
e quando
il pacchetto sorgente è spacchettato le patch elencate nel
debian/patches/series
vengono applicate
automaticamente. Come suggerisce il nome, le patch possono essere gestite
con quilt.
Quando si utilizza il più anziano sorgente «1.0», è anche possibile separare
le patch, ma un sistema di patch dedicato deve essere utilizzato: i file di
patch sono distribuiti all'interno del file di patch Debian
(diff.gz
.), di solito nella cartella
debian/
. L'unica differenza è che non vengono applicate
immediatamente da dpkg-source, ma dalla regola
build
di debian/rules
, attraverso
una dipendenza dalla regola patch
. Al contrario, essi
sono annullati nella regola clean
, attraverso una
dipendenza dalla regola unpatch
.
quilt è lo strumento consigliato per questo. Fa tutto
quanto detto precedentemente e permette anche di gestire le serie di
patch. Si veda il pacchetto quilt
per ulteriori informazioni.
Ci sono altri strumenti per gestire le patch, come dpatch
e il sistema di patch integrato con cdbs
.
Un singolo pacchetto sorgente costruirà spesso diversi pacchetti binari, sia
per fornire diverse versioni dello stesso software (ad esempio, il pacchetto
sorgente vim
) o per fare diversi
piccoli pacchetti invece di uno grande (ad esempio, in modo che l'utente
possa installare solo il sottoinsieme necessario e quindi di risparmiare
spazio su disco).
Il secondo caso può essere facilmente gestito in
debian/rules
. Bisogna solo spostare i file appropriati
dalla cartella di compilazione in alberi temporanei del pacchetto. È
possibile farlo utilizzando install o
dh_install da debhelper
. Ci si assicuri di controllare le
diverse permutazioni dei vari pacchetti, assicurandosi di avere il corretto
insieme di dipendenze tra pacchetti in debian/control
.
Il primo caso è un po' più difficile in quanto comporta molteplici
ricompilazioni dello stesso software, ma con diverse opzioni di
configurazione. Il pacchetto sorgente vim
è un esempio di come gestirlo utilizzando un
file debian/rules
scritto a mano.
Le seguenti pratiche sono rilevanti per il
filedebian/control
. Esse integrano la Policy sulla
descrizione dei pacchetti.
La descrizione del pacchetto, come definito dal corrispondente campo nel
file control
, contiene sia la sinossi del pacchetto sia
la descrizione lunga del pacchetto. Sezione 6.2.1, «Linee guida generali per le descrizioni dei pacchetti»
descrive le linee guida comuni ad entrambe le parti della descrizione del
pacchetto. In seguito, Sezione 6.2.2, «La sinossi del pacchetto, o una breve descrizione» fornisce
specifiche linee guida per la sinossi e Sezione 6.2.3, «La descrizione lunga»
contiene specifiche linee guida per la descrizione.
La descrizione del pacchetto dovrebbe essere scritta probabilmente per l'utente medio, la persona media che utilizzerà ed avrà benefici dal pacchetto. Per esempio, pacchetti di sviluppo sono per gli sviluppatori e possono essere di natura tecnica nella loro linguaggio. Applicazioni più generiche, come gli editor, dovrebbero essere scritte per un utente meno tecnico.
La nostra analisi delle descrizioni dei pacchetti ci porta a concludere che la maggior parte delle descrizioni dei pacchetti sono di natura tecnica, cosi è, non sono scritte per avere senso per gli utenti non tecnici. A meno che il proprio pacchetto non sia realmente solo per utenti tecnici, questo costituisce un problema.
Come si scrive per gli utenti non tecnici? Si eviti il gergo. Evitare di riferirsi ad altre applicazioni o framework che l'utente potrebbe non conoscere - GNOME o KDE va bene, dal momento che gli utenti hanno probabilmente familiarità con questi termini, ma GTK+ probabilmente non lo è. Cercare di ipotizzare nessuna conoscenza a priori. Se è necessario utilizzare termini tecnici, spiegarli.
Si sia obiettivi. Le descrizioni dei pacchetti non sono il posto per promuovere il proprio pacchetto, non importa quanto lo si ami. Ricordare che il lettore potrebbe non essere interessato alle stesse cose che vi interessano.
I riferimenti ai nomi di eventuali altri pacchetti software, nomi di protocollo, standard o specifiche dovrebbero utilizzare la forma canonica, se ne esiste una. Ad esempio, utilizzare X Window System, X11 o X, non X Windows, X-Windows o X Window. Utilizzare GTK +, non GTK o gtk. Usare GNOME, non Gnome. Utilizzare PostScript, non Postscript o postscript.
Se si hanno problemi di scrittura della descrizione, si potrebbe desiderare
di inviarla all'indirizzo di posta elettronica <debian-l10n-english@lists.debian.org>
richiedendo un parere.
La policy dice che la linea di sinossi (la breve descrizione) deve essere concisa ma anche informativa, non ripetendo il nome del pacchetto.
Le sinossi funziona come una frase che descrive il pacchetto, non una frase completa, perciò la punteggiatura è inappropriata: non ha bisogno di lettere maiuscole in più o un punto finale (punto). Dovrebbe anche omettere qualsiasi iniziale articolo indefinito o definito - «a», «un» o «il». Così, per esempio:
Package: libeg0 Description: esempio di libreria di supporto
Tecnicamente si tratta di un sintagma nominale senza articoli, al contrario
di una frase verbale. Una buona euristica è che dovrebbe essere possibile
sostituire il nome
e la
sinossi
del pacchetto in questa formula:
Il pacchetto name
fornisce {a, un, il, alcuni}
sinossi
.
Insiemi di pacchetti correlati possono utilizzare uno schema alternativo che divide la sinossi in due parti, la prima una descrizione di tutta la suite e la seconda una sintesi del ruolo del pacchetto all'interno di essa:
Package: eg-tools Description: simple exemplification system (utilities) Package: eg-doc Description: simple exemplification system - documentation
Queste sinossi seguono una formula modificata. Quando un pacchetto
«name
» ha una «suite
di sinossi (role
) » o
«suite
- role
», gli
elementi devono essere formulati in modo che si inseriscano nella formula:
Il name
del pacchetto fornisce {a, un, il}
role
per la suite
.
La descrizione lunga è la principale informazione sul pacchetto disponibile agli utenti prima che lo si installi. Essa dovrebbe fornire tutte le informazioni necessarie per permettere all'utente di decidere se installare il pacchetto. Si supponga che l'utente abbia già letto la sinossi del pacchetto.
La descrizione lunga deve essere composta da frasi complete ed esaustive.
Il primo paragrafo della descrizione lunga deve rispondere alle seguenti domande: che cosa fa il pacchetto? in che modo aiuta l'utente ad assolvere ai suoi task? È importante descrivere ciò in maniera non tecnica, salvo ovviamente quando il pacchetto è destinato ad una utenza tecnica.
I paragrafi che seguono devono rispondere alle seguenti domande: Perché, come utente, ho bisogno di questo pacchetto? Quali altre caratteristiche ha il pacchetto? Quali le caratteristiche e le carenze ci sono rispetto ad altri pacchetti (per esempio, se si ha bisogno di X, usare Y invece)? Questo pacchetto è correlato ad altri pacchetti in qualche modo che non viene gestito dal gestore di pacchetti (per esempio, questo è il client per il server foo)?
Fare attenzione ad evitare errori di ortografia e di grammatica. Ci si
assicuri di effettuare il controllo ortografico. Entrambi
ispell e aspell hanno modalità
speciali per il controllo del file debian/control
:
ispell -d american -g debian/control
aspell -d en -D -c debian/control
Gli utenti di solito si aspettano che queste domande ricevano risposta nella descrizione del pacchetto:
Che cosa fa il pacchetto? Se si tratta di un componente aggiuntivo per un altro pacchetto, allora la breve descrizione del pacchetto per il quale è un componente aggiuntivo dovrebbe essere inserita qui.
Perché dovrei volere questo pacchetto? Questo è legato al precedente, ma non è lo stesso (questo è un client di posta elettronica; questo è eccezionale, veloce, si interfaccia con PGP e LDAP e IMAP, ha caratteristiche X, Y e Z).
Se il pacchetto non deve essere installato direttamente, ma è richiamato da un altro pacchetto, questo dovrebbe essere menzionato.
Se il pacchetto è experimental
, o ci sono altri motivi
per i quali non dovrebbe essere usato, se invece ci sono altri pacchetti che
dovrebbero essere utilizzati, esso dovrebbe essere indicato.
In che modo questo pacchetto si differenzia da altri? È un'implementazione migliore? più funzioni? caratteristiche diverse? Perché dovrei scegliere questo pacchetto.
Si consiglia di aggiungere l'URL per la home page del pacchetto nel campo
Homepage
della sezione Source
in
debian/control
. L'aggiunta di questa informazione nella
descrizione del stesso pacchetto è considerata obsoleta.
Ci sono campi aggiuntivi per la posizione del Version Control System in
debian/control
.
Il valore di questo campo dovrebbe essere una URL http://
che punta a una copia web navigabile del Version Control System utilizzato
per mantenere il pacchetto, se disponibile.
L'informazione è destinata ad essere utile per l'utente finale, disposto a
sfogliare l'ultimo lavoro svolto sul pacchetto (ad esempio quando si cerca
la patch di un bug etichettato come pending
nel sistema
di bug tracking).
Il valore di questo campo deve essere una stringa che identifica in modo
inequivocabile la posizione del repository del Version Control System
utilizzato per mantenere il pacchetto, se disponibile. *
individua il Version Control System; attualmente i seguenti sistemi sono
supportati dal package tracking system: arch
,
bzr
(Bazaar), cvs
,
darcs
, git
, hg
(Mercurial), mtn
(Monotone), svn
(Subversion). È consentito specificare diversi campi VCS per lo stesso
pacchetto: saranno tutti mostrati nell'interfaccia web di PTS.
L'informazione è destinata ad essere utile per un utente esperto nel dato Version Control System e disposto a compilare la versione attuale del pacchetto dai sorgenti VCS. Altri usi di queste informazioni possono includere compilazioni automatiche della versione VCS più recente del dato pacchetto. A tal fine la posizione a cui punta il campo dovrebbe essere la versione migliore rispetto a quella agnostica e puntare al ramo principale (per i VCS che supportano tale concetto). Inoltre, la posizione indicata dovrebbe essere accessibile per l'utente finale; soddisfare questo requisito potrebbe implicare un accesso anonimo al repository invece di puntare a una versione SSH-accessibile dello stesso.
Nel seguente esempio è mostrata un'istanza del campo per un repository
Subversion del pacchetto vim
. Si
noti come l'URL è nello schema svn://
(invece di
svn+ssh://
) e come si punti al branch
trunk/
. È anche mostrato l'uso dei campi del
Vcs-Browser
e Homepage
descritti
precedentemente.
Source: vim Section: editors Priority: optional <snip> Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim Homepage: http://www.vim.org
Le seguenti pratiche integrano la Policy sui file changelog.
La voce del changelog inerente una revisione del pacchetto documenta i cambiamenti in quella specifica revisione e solo loro. Concentrarsi sulla descrizione di cambiamenti significativi e visibili all'utente che sono stati fatti dopo l'ultima versione.
Ci si concentri su ciò che è stato cambiato: chi, come e quando di solito sono meno importanti. Detto questo, ricordarsi di citare le persone che hanno fornito un notevole aiuto nel compilare il pacchetto (ad esempio, coloro che hanno inviato delle patch).
Non c'è bisogno di elaborare le modifiche banali e ovvie. È inoltre
possibile aggregare diversi cambiamenti in un'unica voce. D'altra parte, non
si sia troppo ermetici se si ha intrapreso un cambiamento importante. Si sia
particolarmente chiari se ci sono cambiamenti che influenzano il
comportamento del programma. Per ulteriori chiarimenti, utilizzare il
README.Debian
.
Si utilizzi l'inglese comune in modo che la maggior parte dei lettori possa comprenderlo. Si evitino abbreviazioni, termini tecnici e gergo quando si spiegano i cambiamenti che chiudono i bug, soprattutto per i bug segnalati dagli utenti che non sembrano particolarmente smaliziati dal punto di vista tecnico. Si sia gentili, non si imprechi.
A volte è desiderabile far precedere le voci del changelog con i nomi dei file che sono stati modificati. Tuttavia, non c'è bisogno di elencare esplicitamente uno per uno tutti i file modificati, soprattutto se il cambiamento è stato piccolo o ripetitivo. È possibile utilizzare i metacaratteri.
Quando si parla di bug, non si dia per scontato nulla. Dire quale era il problema, come è stato risolto e aggiungere in fondo la stringa closes: #nnnnn. Per ulteriori informazioni, si consulti Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload».
Le voci del changelog non dovrebbero documentare generici problemi di packaging (Ehi, se si è alla ricerca di foo.conf, è in /etc/blah/.), dal momento che si suppone che gli amministratori e gli utenti siano a conoscenza di come queste cose sono generalmente gestite sui sistemi Debian. Parlatene, tuttavia, se si modifica la posizione di un file di configurazione.
Gli unici bug chiusi con una voce nel changelog dovrebbero essere quelli che sono effettivamente chiusi nella stessa versione del pacchetto. Chiudere bug non correlati nel changelog è cattiva pratica. Si veda Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload».
Le voci del changelog non dovrebbero essere utilizzate per discussioni casuali con chi ha segnalato il bug (non vedo segmentation fault quando avvio foo con l'opzione bar; invia più informazioni al riguardo), dichiarazioni generali sulla vita, l'universo e tutto il resto (scusate questo caricamento mi ha preso così tanto tempo, ma ho preso l'influenza), o richieste di aiuto (la lista di bug su questo pacchetto è enorme, vi prego di dare una mano). Queste cose di solito non vengono notate, ma possono infastidire le persone che desiderano leggere le informazioni sulle modifiche effettive nel pacchetto. Per ulteriori informazioni su come utilizzare il sistema di bug tracking vedere Sezione 5.8.2, «Rispondere ai bug».
Si tratta di una vecchia tradizione per riconoscere bug corretti in un caricamento di un non-maintainer nella prima voce del changelog dell'appropriato maintainer. Siccome ora abbiamo il version tracking, è sufficiente mantenere le voci del changelog NMUed e citare questo fatto nella propria voce del changelog.
I seguenti esempi dimostrano alcuni errori comuni o di cattivo stile nelle voci del changelog.
* Fixed all outstanding bugs.
Questo non dice ai lettori qualcosa di particolarmente utile, ovviamente.
* Applied patch from Jane Random.
Qual'era l'argomento della patch?
* Late night install target overhaul.
Revisione che ha completato cosa? L'ipotetica citazione notturna è lì a ricordarci che non dovremmo fidarci di quel codice?
* Fix vsync FU w/ ancient CRTs.
Troppe sigle e non è troppo chiaro a quale la, uh, fsckup (ops, una parolaccia!) si riferiva, o come è stato sistemato.
* This is not a bug, closes: #nnnnnn.
Innanzitutto, non c'è assolutamente alcun bisogno di caricare il pacchetto per trasmettere queste informazioni; invece, utilizzare il sistema di bug tracking. In secondo luogo, non c'è alcuna spiegazione del perché il rapporto non è un bug.
* Has been fixed for ages, but I forgot to close; closes: #54321.
Se per qualche motivo non si è citato il numero di bug in una voce precedente del changelog, non è un problema, basta chiudere normalmente il bug nel BTS. Non c'è bisogno di toccare il file changelog, presumendo che la descrizione della correzione sia già indicata (questo vale per le correzioni da parte degli autori/manutentori, non c'è bisogno di tenere traccia dei bug che hanno risolto secoli fa nel proprio changelog).
* Closes: #12345, #12346, #15432
Dov'è la descrizione? Se non è possibile pensare ad un messaggio descrittivo, iniziare inserendo il titolo di ogni differente bug.
Importanti novità sui i cambiamenti in un pacchetto possono anche essere
inserite nei file NEWS.Debian
. Le notizie saranno
visualizzate da strumenti come apt-listchanges
, prima di tutto il resto dei
changelog. Questo è il mezzo preferito per permettere all'utente di
conoscere i cambiamenti significativi in ??un pacchetto. È meglio che usare
le note di debconf
in quanto è meno
fastidioso e l'utente può tornare indietro e vedere il file
NEWS.Debian
dopo l'installazione. Ed è meglio rispetto
all'elencare i principali cambiamenti presenti in
README.Debian
, dal momento che l'utente può facilmente
perderli.
Il formato del file è lo stesso di un file changelog Debian, ma lasciare
fuori gli asterischi e descrivere ogni notizia con un paragrafo completo
quando necessario, piuttosto che le più concise sintesi che andrebbero in un
changelog. È una buona idea eseguire il file attraverso
dpkg-parsechangelog
per controllare la formattazione in
quanto durante la fase di compilazione non sarà controllata automaticamente
come è stato fatto per il changelog. Ecco un esempio di un vero e proprio
file NEWS.Debian
:
cron (3.0pl1-74) unstable; urgency=low The checksecurity script is no longer included with the cron package: it now has its own package, checksecurity. If you liked the functionality provided with that script, please install the new package. -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
Il file NEWS.Debian
è installato come
/usr/share/doc/
.
È compresso e ha sempre quel nome, anche in pacchetti nativi Debian. Se si
utilizza package
/NEWS.Debian.gzdebhelper
,
dh_installchangelogs
installerà il file
debian/NEWS
per voi.
A differenza dei file changelog, non è necessario aggiornare il file
NEWS.Debian
ad ogni rilascio. Aggiornarli solo se si ha
qualcosa particolarmente degna di nota che l'utente dovrebbe conoscere. Se
non si ha alcuna notizia, non c'è bisogno di fornire un file
NEWS.Debian
. Nessuna notizia è una buona notizia!
Gli script del maintainer includono i file
debian/postinst
, debian/preinst
,
debian/prerm
e
debian/postrm
. Questi script si prendono cura di ogni
configurazione di installazione o disinstallazione del pacchetto che non è
gestito esclusivamente dalla creazione o dalla rimozione di file e
cartelle. Le seguenti istruzioni completano la Debian Policy.
Gli script del maintainer devono essere idempotenti. Ciò significa che è necessario assicurarsi che nulla di male accadrà se lo script dovesse essere invocato due volte dove di solito viene lanciato una volta sola.
Gli standard input e output possono essere reindirizzati (ad esempio nelle pipe) per finalità di logging, quindi non utilizzateli come una tty.
Tutte le configurazioni suggerite o interattive devono essere ridotte al
minimo. Quando è necessario, si dovrebbe utilizzare il pacchetto debconf
per l'interfaccia. Ricordare che il
suggerimento in ogni caso può esserci solo nella fase
configure
dello script postinst
.
Mantenere gli script del maintainer più semplici possibile. Si consiglia di
utilizzare puri script POSIX. Ricordate, se si ha bisogno di tutte le
funzioni di bash, lo script del maintainer deve avere una linea shebang per
bash. La shell POSIX o Bash sono preferite a quella Perl, poiché permettono
a debhelper
di aggiungere facilmente
bit agli script.
Se si modificano gli script del maintainer, assicurarsi di testare la rimozione del pacchetto, la doppia installazione e l'epurazione. Assicurarsi che un pacchetto epurato sia completamente sparito, ovvero, deve rimuovere tutti i file creati, direttamente o indirettamente, in tutti gli script del maintainer.
Se è necessario verificare l'esistenza di un comando, si dovrebbe usare qualcosa simile a
if [ -x /usr/sbin/install-docs ]; then...
Se non si desidera codificare il percorso di un comando nello script del maintainer, la seguente funzione shell che soddisfa POSIX potrebbe essere d'aiuto:
pathfind() { OLDIFS="$IFS" IFS=: for p in $PATH; do if [ -x "$p/$*" ]; then IFS="$OLDIFS" return 0 fi done IFS="$OLDIFS" return 1 }
Si può utilizzare questa funzione per cercare il $PATH
di
un nome di un comando, passato come argomento. Restituisce true (zero) se il
comando è stato trovato e false in caso contrario. Questo è davvero il modo
più portatile, dal momento che command -v
,
type e which non sono POSIX.
Mentre which è una alternativa accettabile, dal momento
che fa parte del richiesto pacchetto debianutils
, non è nella partizione di
root. Ovvero, è in /usr/bin
, piuttosto che
/bin
, quindi non può essere utilizzato in script che
vengono eseguiti prima che la partizione /usr
sia
montata. La maggior parte degli script non avranno questo problema, però.
Debconf
è un sistema di gestione
della configurazione che può essere utilizzato da tutti i vari script per la
pacchettizzazione (principalmente postinst
) per
richiedere indicazioni all'utente riguardo a come configurare il
pacchetto. Interazioni dirette degli utenti ora devono essere evitate a
favore dell'interazione con debconf
. Ciò consentirà installazioni non
interattive in futuro.
Debconf è un grande strumento, ma è spesso mal utilizzato. Molti errori comuni sono elencati nella pagina man di debconf-devel(7). È qualcosa che si deve leggere se si decide di usare debconf. Inoltre, indichiamo qui alcune buone pratiche.
Queste linee guida comprendono un certo stile di scrittura e di raccomandazioni tipografiche, considerazioni generali sull'uso di debconf e raccomandazioni più specifiche per alcune parti della distribuzione (il sistema di installazione, per esempio).
Da quando debconf è apparso in Debian, è stato ampiamente abusato e diverse critiche ricevute dalla distribuzione Debian provengono dall'abuso di debconf con la necessità di rispondere ad una vasta serie di domande prima di installare ogni piccola cosa.
Riservare le note d'uso a ciò cui appartengono: al file
NEWS.Debian
, o README.Debian
. Le
si utilizzi solamente per le note importanti che possono influenzare
direttamente l'usabilità del pacchetto. Ricordare che le note bloccheranno
sempre l'installazione fino a quando saranno confermate o abbiano disturbato
l'utente tramite email.
Scegliere con cura le priorità delle domande negli script del maintainer. Si consulti debconf-devel(7) per i dettagli sulla priorità. La maggior parte delle domande dovrebbero usare le priorità media e bassa.
La maggior parte dei maintainer dei pacchetti Debian non sono di madrelingua inglese. Quindi, la scrittura di modelli correttamente formulati, può non essere facile per loro.
utilizzare (e abusare) della mailing list
<debian-l10n-english@lists.debian.org>
. Avrete le vostre bozze di modelli corrette.
I modelli scritti male danno una cattiva immagine del pacchetto, del proprio lavoro... o anche di Debian stesso.
Evitare il gergo tecnico il più possibile. Se alcuni termini suonano comuni a voi, possono essere impossibili da comprendere per gli altri. Se non si possono evitare, cercare di spiegarli (utilizzare la descrizione estesa). Nel fare ciò, cercare di bilanciarsi tra verbosità e semplicità.
I modelli debconf possono essere tradotti. Debconf, insieme al suo pacchetto fratello po-debconf offre un framework semplice per ottenere i modelli tradotti dai team di traduzione o anche dai singoli individui.
Utilizzare i modelli basati su gettext. Installare po-debconf
sul proprio sistema di sviluppo e
leggete la sua documentazione (man po-debconf è un buon
inizio).
Evitare di modificare i modelli troppo spesso. Cambiare i modelli di testo
produce più lavoro per i traduttori che avranno la loro traduzione
confusa. Una traduzione confusa è una frase per la quale l'originale sia
stata cambiata da quando è stata tradotta, quindi per essere utilizzabile
richiede alcuni aggiornamenti da parte di un traduttore. Quando i
cambiamenti sono abbastanza piccoli, la traduzione originale è conservata
nel file PO, ma contrassegnata come fuzzy
.
Se si ha intenzione di modificare i modelli originali, utilizzare il sistema
di notifica fornito con il pacchetto po-debconf
, vale a dire il
podebconf-report-po, per contattare i traduttori. I
Traduttori più attivi sono molto reattivi e ottenere il loro lavoro incluso
insieme con i vostri modelli modificati vi risparmierà caricamenti
aggiuntivi. Se si utilizzano modelli basati su gettext, il nome del
traduttore e gli indirizzi di posta elettronica sono menzionati negli header
dei file PO e saranno utilizzati da podebconf-report-po.
Un uso consigliato di ciò che questa utility è:
cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"
Questo comando innanzitutto sincronizzerà i files PO e POT in
debian/po
con i file dei modelli elencati in
debian/po/POTFILES.in
. Poi, invierà una richiesta di
nuove traduzioni, nella mailing list <debian-i18n@lists.debian.org>
. Infine, invierà
una richiesta per aggiornare la traduzione sia al team per il supporto della
lingua (menzionato nel campo Language-Team
di ogni file
PO), sia all'ultimo traduttore (menzionato nel campo
Last-translator
).
Dare una scadenza ai traduttori è sempre apprezzato, in modo tale che possano organizzare il loro lavoro. Ricordare che alcuni gruppi di traduzione hanno un processo formalizzato di traduzione/revisione e un ritardo inferiore a 10 giorni è considerato irragionevole. Un ritardo più breve mette troppa pressione sul team di traduzione e dovrebbe essere utilizzato per modifiche di minore entità.
In caso di dubbio, si può anche contattare il team di traduzione per una
determinata lingua (debian-l10n-xxxxx@lists.debian.org), o la mailing list
<debian-i18n@lists.debian.org>
.
Quando il testo di un modello debconf è corretto e si è sicuri che la modifica non influenzi le traduzioni, si sia gentili con i traduttori e sistemare le loro traduzioni.
Se non si fa così, l'intero modello non verrà tradotto fino a quando un traduttore invierà un aggiornamento.
Per sistemare le traduzioni, è possibile utilizzare
msguntypot (parte del pacchetto po4a
).
Rigenerare i file POT e PO.
debconf-updatepo
Creare una copia del file POT.
cp templates.pot templates.pot.orig
Fare una copia di tutti i files PO.
mkdir po_fridge; cp *.po po_fridge
Modificare i file dei modelli di debconf per correggere errori di battitura.
Rigenerare i file POT e PO (di nuovo).
debconf-updatepo
A questo punto, la correzione dell'errore di battitura ha confuso tutte le traduzioni e questo spiacevole cambiamento è l'unico tra i file PO della vostra cartella principale e quella in frigo. Ecco come risolvere questa situazione.
Scartare la traduzione disordinata, ripristinare quella proveniente dal frigo.
cp po_fridge/*.po.
Unire manualmente i files PO con il nuovo file POT, ma prendendo nell'account l'inutile disordine.
msguntypot -o templates.pot.orig -n templates.pot *.po
Pulizia.
rm -rf templates.pot.orig po_fridge
I modelli di testo non dovrebbero fare riferimento ai widget appartenenti ad alcune interfacce di debconf. Frasi come Se rispondi SI... non hanno alcun significato per gli utenti di interfacce grafiche che utilizzano checkbox per le domande booleane.
I modelli di frasi dovrebbero anche evitare di menzionare i valori predefiniti nella loro descrizione. Primo, perché questo è ridondante con i valori visualizzati dagli utenti. Inoltre, perché questi valori predefiniti possono essere diversi dalle scelte del maintainer (per esempio, quando il database debconf è stato preconfigurato).
Più in generale, cercare di evitare di riferirsi alle azioni dell'utente. Basta indicare i fatti.
Si dovrebbe evitare l'uso della prima persona (Farò questo... o Consigliamo...). Il computer non è una persona ed i modelli debconf non parlano a nome degli sviluppatori Debian. Si dovrebbe usare la costruzione impersonale. Per coloro di voi che già hanno scritto pubblicazioni scientifiche, basta scrivere i vostri modelli come quando si scrive un articolo scientifico. Tuttavia, provare a utilizzare la voce attiva, se ancora possibile, come Abilitate questo se..., invece di Questo può essere attivata se... .
Questa parte fornisce alcune informazioni che sono per lo più prese dal manuale debconf-devel(7).
Richiede all'utente una password. La si usi con cautela; si sia consapevoli del fatto che la password che l'utente inserisce sarà scritta nel database di debconf. Si dovrebbe cancellare quel valore fuori dal database appena è possibile.
Una scelta tra una serie di valori. Le scelte devono essere specificate in
un campo denominato «Choices». Separare i possibili valori con le virgole e
gli spazi, in questo modo: Scelte: sì, no, forse
.
Se le scelte sono stringhe traducibili, il campo «Choices» può essere
contrassegnato come traducibile utilizzando __Choices
. La
doppia sottolineatura suddividerà ogni scelta in una stringa separata.
Il sistema po-debconf offre anche interessanti possibilità di marcare solamente alcune scelte come traducibili. Esempio:
Template: foo/bar Type: Select #flag:translate:3 __Choices: PAL, SECAM, Other _Description: TV standard: Please choose the TV standard used in your country.
In questo esempio, solo la stringa «Other» è traducibile, mentre altri sono acronimi che non devono essere tradotti. Quanto sopra esposto consente solo ad «Other» di essere inserito nei file PO e POT.
I modelli debconf con sistema a flag offrono molte di queste possibilità. La pagina del manuale di po-debconf(7) elenca tutte queste possibilità.
Come per la selezione del tipo di dato, ad eccezione di quando l'utente può scegliere un qualsiasi numero di elementi dall'elenco delle scelte (o scegliere nessuno di loro).
Piuttosto che essere una questione di per sé, questo tipo di dato indica una nota che può essere visualizzata all'utente. Dovrebbe essere usato solo per le note importanti che l'utente in realtà dovrebbe vedere, dato che debconf andrà incontro a grandi dolori per assicurarsi che l'utente la veda; arrestando l'installazione per consentire loro di premere un tasto persino inviandogli la nota tramite posta elettronica in alcuni casi.
Questo tipo è progettato per gestire i messaggi di errore. È molto simile al tipo di nota. Le interfacce possono presentarlo in modo diverso (per esempio, la finestra di cdebconf disegna uno schermo rosso invece del solito blu).
Si consiglia di utilizzare questo tipo per ogni messaggio che necessita dell'attenzione dell'utente per una correzione di qualsiasi tipo.
Le descrizioni dei modelli constano di due parti: breve ed estesa. La descrizione breve è nella linea «Description:» del modello.
La descrizione breve dovrebbe essere mantenuta breve (50 caratteri o giù di lì) in modo che possa essere accolta dalla maggior parte delle interfacce di debconf. Mantenerla breve aiuta anche i traduttori, considerato che normalmente le traduzioni tendono a finire per essere più lunghe rispetto all'originale.
La descrizione breve dovrebbe essere in grado di stare in piedi da sola. Alcune interfacce non mostrano la descrizione lunga di default, oppure solo se l'utente esplicitamente la chiede o addirittura non la mostrano affatto. Evitare cose come «cosa vuoi fare?»
La descrizione breve non deve necessariamente essere un periodo completo. Questo fa parte della raccomandazione di mantenerla breve ed efficiente.
La descrizione estesa non deve ripetere la descrizione breve parola per parola. Se non è possibile pensare ad una descrizione lunga, quindi primo, si pensi un po' di più. Si condivida in debian-devel. Si chieda aiuto. Ci si iscriva ad un corso di scrittura! La descrizione estesa è importante. Se dopo tutto questo non è ancora possibile trovare qualcosa, la si lasci vuota.
La descrizione estesa dovrebbe usare periodi completi. I paragrafi devono essere brevi per migliorare la leggibilità. Non mescolare due idee nello stesso punto, piuttosto si usi un altro paragrafo.
Non si sia troppo prolissi. Gli utenti tendono a ignorare schermate troppo lunghe. 20 righe sono per esperienza un limite che non si dovrebbe oltrepassare, perché ciò significa che nella finestra di interfaccia classica, le persone avranno bisogno di scorrere e molte persone semplicemente non lo fanno.
La descrizione estesa non dovrebbe mai includere una domanda.
Per specifiche regole inerenti il tipo di template (string, boolean, etc), leggere qui di seguito.
Questo campo dovrebbe essere utilizzato per la selezione singola e multipla dei tipi. Esso contiene le scelte possibili che verranno presentate agli
Nessuna indicazione specifica eccetto: utilizzare il tipo appropriato, facendo riferimento alla sezione precedente.
Qui di seguito sono istruzioni specifiche per scrivere correttamente la descrizione (breve e lunga) a seconda del tipo di modello.
La descrizione breve è un suggerimento e non un titolo. Evitare domande in stile suggerimento (indirizzo IP?) a favore di suggerimenti aperti (indirizzo IP:). Si consiglia l'uso dei due punti.
La descrizione estesa è un complemento della descrizione breve. Nella parte estesa, si spieghi ciò che viene chiesto, piuttosto che riproporre la stessa domanda con parole più lunghe. Utilizzare frasi complete. Una scrittura concisa è fortemente sconsigliata.
La descrizione breve dovrebbe essere formulata in forma di una domanda che dovrebbe essere mantenuta breve e dovrebbe generalmente terminare con un traduzioni sono spesso più lunghe rispetto alle versioni originali).
Anche in questo caso, evitare il riferimento a specifici widget delle interfacce. Un errore comune per tali modelli è se si risponde con costrutti di tipo Yes.
La descrizione breve è un suggerimento e non un titolo. Non utilizzare inutili costrutti del tipo «Gentilmente scegliete...». Gli utenti sono abbastanza intelligenti da capire che devono scegliere qualcosa... :)
La descrizione estesa completerà la descrizione breve. Può far riferimento alle scelte disponibili. Può anche indicare che l'utente può scegliere più di una tra le scelte disponibili, se il modello è di tipo selezione multipla (l'interfaccia spesso rende chiaro tutto ciò).
La descrizione breve dovrebbe essere considerata un titolo.
La descrizione estesa è ciò che sarà visualizzato come una spiegazione più dettagliata della nota. Frasi, non scrittura sintetica.
Non abusare di debconf. Le note sono il
modo più comune per abusare di debconf. Come scritto nella pagina di manuale
di debconf-devel: è meglio usarle solo come avvertimento di problemi molto
seri. I files NEWS.Debian
o
README.Debian
sono il luogo appropriato per molte
note. Se, leggendo questo manuale, si sta valutando di convertire i propri
modelli di tipo Nota in voci di NEWS.Debian
o
README.Debian
, si consideri anche di mantenere le
traduzioni esistenti per il futuro.
Se le «Choises» sono suscettibili di cambiare spesso, considerare l'uso del trucco «__ Choices». Questo dividerà ogni singola scelta in una singola stringa, che aiuterà notevolmente i traduttori nel compiere il loro lavoro.
Se il valore di default, per un modello di selezione, può variare a seconda della lingua dell'utente (per esempio, se la scelta è una scelta della lingua), utilizzare il trucco «_Default».
Questo campo speciale permette ai traduttori di mettere la scelta più appropriata in base alla loro propria lingua. Diventerà la scelta di default quando sarà usato il loro linguaggio mentre la vostra «Scelta di Default» verrà usata quando si utilizza l'inglese.
Esempio, tratto dai modelli del pacchetto geneweb:
Template: geneweb/lang Type: select __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv) # This is the default choice. Translators may put their own language here # instead of the default. # WARNING : you MUST use the ENGLISH NAME of your language # For instance, the french translator will need to put French (fr) here. _Default: English[ translators, please see comment in PO files] _Description: Geneweb default language:
Si noti l'uso dei «cancelletti» che consentano i commenti interni nei campi di debconf. Da notare anche l'uso di commenti che appariranno nel file sui quali i traduttori lavoreranno.
I commenti sono necessari dal momento che il trucco _Default genera un po' di confusione: i traduttori potranno mettere la propria scelta
NON usare un campo predefinito vuoto. Se non si desidera utilizzare i valori di Default, non usarli.
Se si utilizza po-debconf (e si dovrebbe, si consulti Sezione 6.5.2.2, «Sii gentile con i traduttori»), si consideri di marcare questo campo come traducibile, se si pensa che possa essere tradotto.
Se il valore predefinito può variare a seconda della lingua/paese (ad esempio, il valore predefinito per una scelta della lingua), è possibile utilizzare il tipo speciale _Default documentato in po-debconf(7).
Questa sezione contiene le informazioni a livello generale per gli sviluppatori al fine di rendere più facile la vita dei traduttori. Maggiori informazioni per i traduttori e gli sviluppatori interessati alla internazionalizzazione sono disponibili nella documentazione Internazionalizzazione e localizzazione in Debian.
Come gli autori di port, i traduttori hanno un compito difficile. Lavorano su molti pacchetti e devono collaborare con molti maintainer diversi. Inoltre, la maggior parte delle volte, non sono di madrelingua inglese, quindi si potrebbe dover essere particolarmente pazienti con loro.
L'obbiettivo di debconf
era quello
di rendere più facile la configurazione di pacchetti per i maintainer e per
gli utenti. In origine, la traduzione di modelli debconf è stata gestita con
debconf-mergetemplate. Tuttavia, tale tecnica è ormai
deprecata, il modo migliore per realizzare una internazionalizzazione
debconf
è quello di utilizzare il
pacchetto po-debconf
. Questo metodo
è più facile sia per il maintainer e sia per i traduttori; sono forniti
script di transizione.
Utilizzando po-debconf
, la
traduzione è memorizzata in file .po
(prese dalle
tecniche di traduzione gettext). Speciali file di modello
contengono i messaggi originali e marcano quali campi sono
traducibili. Quando si modifica il valore di un campo traducibile, chiamando
debconf-updatepo, la traduzione è contrassegnata come
bisognosa di attenzione da parte dei traduttori. Poi, in fase di
compilazione, il programma dh_installdebconf si prende
cura di tutta la magia necessaria per aggiungere il modello con le
traduzioni aggiornate nei pacchetti binari. Fare riferimento alla pagina del
manuale di po-debconf(7) per i dettagli.
Internazionalizzare la documentazione è fondamentale per gli utenti, ma richiede molto lavoro. Non c'è modo di eliminare tutto quel lavoro, ma si possono rendere le cose più facili per i traduttori.
Se si mantiene una documentazione di qualsiasi dimensione, è più facile per
i traduttori se hanno accesso ad un sistema di controllo del codice
sorgente. Ciò consente ai traduttori di vedere le differenze tra due
versioni della documentazione, così, per esempio, si può vedere ciò che deve
essere ritradotto. Si raccomanda che la documentazione tradotta mantenga una
nota circa la versione del codice sulla quale è basata. Un sistema
interessante è fornito dal doc-check nel pacchetto debian-installer
, che mostra una panoramica
dello stato di traduzione per ogni lingua, utilizzando i commenti
strutturati per la revisione in corso del file da tradurre e, per un file
tradotto, la revisione del file originale della traduzione sulla quale si
basa. Si potrebbe desiderare di adattarla e di fornirla nel proprio VCS.
Se si mantiene la documentazione XML o SGML, vi consigliamo di isolare qualsiasi informazione indipendente dal linguaggio e definirla come entità in un file separato che è incluso da tutte le diverse traduzioni. Ciò rende molto più facile, per esempio, mantenere gli URL aggiornati in più file.
Alcuni strumenti (ad es po4a
,
poxml
, o il translate-toolkit
) sono specializzati
nell'estrazione del materiale traducibile da diversi formati. Producono i
file PO, un formato abbastanza comune ai traduttori, che permette di vedere
ciò che deve essere ritradotto quando il documento tradotto viene
aggiornato.
Mantenere i file config.sub
e
config.guess
di autoconf aggiornati
è fondamentale per gli autori di port, soprattutto su architetture più
volatili. Alcune ottime pratiche di packaging per ogni pacchetto che usa
autoconf e/o automake sono state
sintetizzate in /usr/share/doc/autotools-dev/README.Debian.gz
dal pacchetto autotools-dev
. Si è vivamente incoraggiati a
leggere questo file e di seguire le raccomandazioni in esso fornite.
Le librerie sono sempre difficili da pacchettizzare per vari motivi. La policy impone molti vincoli per facilitare il loro mantenimento e per assicurarsi che gli aggiornamenti siano i più semplici possibili quando una nuova versione viene pubblicata. Una rottura in una libreria può causare una rottura in decine di pacchetti dipendenti.
Delle buone pratiche per la pacchettizzazione delle librerie sono state raggruppate in Guida alla pacchettizzazione delle librerie.
Assicurarsi di seguire la policy Policy sulla documentazione.
Se il pacchetto contiene la documentazione compilata a partire da XML o SGML, si consiglia di non includere il sorgente XML o SGML nel pacchetto binario. Se gli utenti vogliono il sorgente della documentazione, dovrebbero poter recuperare il pacchetto sorgente.
La policy specifica che la documentazione deve essere fornita in formato HTML. Si consiglia anche di inserire la documentazione in formato PDF e testo normale se conveniente e se è possibile output di discreta qualità. Tuttavia, non è in genere appropriato includere la versione in testo semplice della documentazione il cui formato sorgente è HTML.
La maggior parte dei manuali dovrebbe registrarsi con doc-base
durante l'installazione. Si consulti la
documentazione del pacchetto doc-base
per ulteriori informazioni.
La policy di Debian (sezione 12.1) indica che le pagine del manuale dovrebbero accompagnare ogni programma, utility e la funzione e suggerirli per altri oggetti come file di configurazione. Se il lavoro che si sta pacchettizzando non ha queste pagine di manuale, si consideri la loro scrittura per l'inclusione nel pacchetto e di sottoporla allo sviluppatore originale.
Le pagine man non necessitano di essere scritte direttamente in formato troff. I formati file più diffusi sono DocBook, POD e di reST, che possono essere convertiti usando xsltproc, pod2man e rst2man rispettivamente. In misura minore, il programma help2man può anche essere utilizzato per scrivere uno stub.
Vari tipi specifici di pacchetti hanno particolari sub-politiche e rispettive pratiche e regole per la pacchettizzazione:
I relativi pacchetti Perl hanno una Perl
policy, alcuni esempi di pacchetti che seguono tale policy sono
libdbd-pg-perl
(modulo binario perl)
o libmldbm-perl
(modulo perl
indipendente dall'architettura).
I relativi pacchetti Python hanno la loro policy python; si consulti
/usr/share/doc/python/python-policy.txt.gz
nel pacchetto python
.
I relativi pacchetti Emacs hanno la emacs policy.
I relativi pacchetti Java hanno la loro java policy.
I relativi pacchetti Ocaml hanno la loro politica, che si trova in
/usr/share/doc/ocaml/ocaml_packaging_policy.gz
del pacchetto ocaml
. Un buon esempio è il pacchetto dei
sorgenti di camlzip
.
I pacchetti che forniscono XML o SGML DTD devono essere conformi alle
indicazioni fornite nel pacchetto sgml-base-doc
.
I pacchetti Lisp si devono registrare con il common-lisp-controller
, a proposito del quale si
veda /usr/share/doc/common-lisp-controller/README.packaging
.
Non è raro avere una grande quantità di dati indipendenti dall'architettura pacchettizzati con un programma. Ad esempio, i file audio, una collezione di icone, modelli di wallpaper, o altri file grafici. Se la dimensione di questi dati è trascurabile rispetto alle dimensioni del resto del pacchetto, probabilmente è meglio tenere il tutto in un unico pacchetto.
Tuttavia, se la dimensione dei dati è notevole, si consideri di dividere in
un pacchetto separato, indipendente dall'architettura
(_all.deb
). In questo modo, si evitano inutili
duplicazioni degli stessi dati in undici o più .debs, uno per ogni
architettura. Mentre questo aggiunge un po' di overhead ai file dei
Pacchetti
, fa risparmiare molto spazio su disco sui
mirror Debian. Separare i dati indipendenti dall'architettura riduce anche
il tempo di elaborazione di lintian (si consulti Sezione A.2, «Strumenti per la pulizia di pacchetti») quando lanciato sull'intero archivio Debian.
Se si ha bisogno di una certa localizzazione durante la compilazione, si può creare un file temporaneo con questo trucco:
Se si imposta LOCPATH
all'equivalente di
/usr/lib/locale
e LC_ALL
al nome del
locale che si genera, si dovrebbe ottenere ciò che si desidera senza essere
root. Qualcosa di simile a questo:
LOCALE_PATH=debian/tmpdir/usr/lib/locale LOCALE_NAME=en_IN LOCALE_CHARSET=UTF-8 mkdir -p $LOCALE_PATH localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET # Using the locale LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
Deborphan è un programma per aiutare gli utenti ad individuare quali pacchetti possono essere tranquillamente rimossi dal sistema, vale a dire quelli che non hanno pacchetti dipendenti da loro. Il funzionamento predefinito è di cercare solo all'interno delle sezioni libs e oldlibs, per dare la caccia a librerie inutilizzate. Ma quando viene passato l'argomento giusto, cerca di catturare altri pacchetti inutili.
Ad esempio, con --guess-dummy
,
deborphan prova a cercare tutti i pacchetti di
transizione che sono stati necessari per l'aggiornamento, ma che ora possono
tranquillamente essere rimossi. Per questo, esso cerca la stringa dummy or
transitional nella loro descrizione breve.
Quindi, quando si crea un pacchetto di questo tipo, ci si assicuri di aggiungere il testo alla descrizione breve. Se si è alla ricerca di esempi, basta eseguire:apt-cache search.| grep dummy o apt-cache search | grep transitional.
Inoltre, è raccomandato modificare la sua sezione in
oldlibs
e la sua priorità in extra
in
modo da cancellare il compito di deborphan.
Ci sono due tipi di tarball dei sorgenti originali: sorgente puro e sorgente originale ripacchettizzato.
La caratteristica distintiva di un tarball sorgente incontaminato è che il
.orig.tar.{gz,bz2,xz}
è byte-per-byte identico a un
tarball ufficialmente distribuito dall'autore originale. [5] Questo rende possibile l'utilizzo di checksum per
verificare facilmente che tutte le modifiche tra la versione di Debian e
quella originale siano contenute nel Debian diff. Inoltre, se il sorgente
originale è enorme, gli autori originali e chiunque possieda già l'archivio
originale possono risparmiare tempo di download, se vogliono ispezionare il
pacchetto in dettaglio.
Non ci sono linee guida universalmente accettate che gli autori originali seguono per quanto riguarda la struttura delle cartelle all'interno del loro tarball, ma dpkg-source è tuttavia in grado di affrontare la maggior parte delle tarball originali come sorgente puro. La sua strategia è equivalente alla seguente:
Si scompatta l'archivio in una cartella temporanea vuota facendo
zcat path/to/packagename
_upstream-version
.orig.tar.gz | tar xf -
Se, dopo questo, la cartella temporanea non contiene nulla, ma una sola
cartella e nessun altro file, dpkg-source rinomina quella
cartella in
. Il nome della più alta cartella nella tarball non ha
importanza, ed è tralasciata.
packagename
-upstream-version
(.orig)
In caso contrario, l'archivio originale deve essere stato confezionato senza
una comune cartella di livello alto (vergogna sull'autore originale!). In
questo caso, dpkg-source rinomina la cartella temporanea
stessa in
.
packagename
-upstream-version
(.orig)
Si dovrebbe caricare i pacchetti con un tarball sorgente puro, se possibile, ma ci sono vari motivi per cui potrebbe non essere possibile. Questo è il caso in cui se l'autore originale non distribuisce il sorgente come non completamente compresso in formato tar, o se il tarball originale contiene materiale non DFSG-free che è necessario rimuovere prima di caricare.
In questi casi, lo sviluppatore deve costruirsi un
.orig.tar.{gz,bz2,xz}
adatto. Ci si riferisce a un tale
tarball come sorgente originale ripacchettizato. Si noti che un sorgente
originale ripacchettizato è diverso da un pacchetto Debian nativo. Un
sorgente originale ripacchettizato con modifiche specifiche per Debian
ancora viene distribuito in un separato .diff.gz
o
.debian.tar.{gz,bz2,xz}
e ha ancora un numero di
versione composto da upstream-version
e
debian-version
.
Ci possono essere casi in cui è auspicabile pacchettizzare nuovamente il
sorgente anche se l'autore originale distribuisce un
.tar.{gz,bz2,xz}
che potrebbe in linea di principio
essere utilizzato nella sua forma originaria. Il più ovvio è se un
significativo risparmio di spazio può essere ottenuto
ricomprimendo l'archivio tar o rimuovendo genuinamente dell'inutile fuffa
dall'archivio originale. Si usi la propria discrezione qui, ma si sia pronti
a difendere la propria decisione se si pacchettizza nuovamente il sorgente
che poteva esser puro.
Un .orig.tar.{gz,bz2,xz}
ripacchettizzato
dovrebbe essere documentata nel pacchetto
sorgente risultante. Informazioni dettagliate su come è stato ottenuto il
sorgente ripacchettizzato e su come questo può essere riprodotto dovrebbero
essere fornite in debian/copyright
. È anche una buona
idea fornire un get-orig-source
target nel proprio
debian/rules
, che ripete il processo, come descritto
nel Policy Manual, Script principale per
la compilazione: debian/rules
.
non dovrebbe contenere qualsiasi tipo di file che non proviene dall'autore originale, o il cui contenuto è stato modificato. [6]
dovrebbe, salvo che per motivi legali,
preservare l'intera infrastruttura per la compilazione e per la portabilità
fornita dall'autore originale. Ad esempio, non è una ragione sufficiente per
omettere un file che viene utilizzato solo quando si compila su MS-DOS. Allo
stesso modo, un Makefile
fornito dall'autore originale
non dovrebbe essere omesso anche se la prima cosa che il proprio
debian/rules
fa è sovrascriverlo eseguendo uno script
di configurazione.
(Motivazione: È comune per gli utenti Debian che hanno bisogno di compilare software per piattaforme non-Debian prendere il sorgente da uno dei mirror Debian piuttosto che cercare di individuare un punto canonico di distribuzione originale).
dovrebbe usare
come nome per la più alta cartella nel suo tarball. Ciò rende possibile
distinguere tarball puri da quelli ripacchettizzati.
packagename
-upstream-version
.orig
dovrebbe essere compresso con gzip o bzip con la massima compressione.
A volte è necessario cambiare file binari contenuti nel tarball originale, o
per aggiungere file binari che non vi sono contenuti. Questo è completamente
supportato quando si usano pacchetti sorgente in formato «3.0 (quilt)», si
consulti la pagina di manuale dpkg-source(1) per i dettagli. Quando si utilizza il vecchio formato «1.0»,
i file binari non possono essere memorizzati nel
.diff.gz
quindi è necessario memorizzare un
uuencoded (o simile) versione del file e decodificarlo in
fase di compilazione in debian/rules
(e spostarlo nella
sua posizione ufficiale).
Un pacchetto di debug è un pacchetto con un nome che termina in -dbg, che contiene ulteriori informazioni che gdb può utilizzare. Poiché i binari di Debian vengono separati di default, le informazioni di debug, compresi i nomi delle funzioni e numeri di riga, non sono disponibili quando si esegue gdb su binari Debian. I pacchetti di debug consentono di installarli agli utenti che hanno bisogno di queste informazioni aggiuntive, senza appesantire un regolare sistema con queste informazioni.
Spetta al maintainer di un pacchetto se creare un pacchetto di debug o meno. I maintainer sono incoraggiati a creare i pacchetti di debug per i pacchetti di libreria, dal momento che questi possono aiutare nel debug di molti programmi legati ad una libreria. In generale, i pacchetti di debug non devono essere aggiunti per tutti i programmi, facendo così appesantire l'archivio. Ma se un maintainer ritiene che gli utenti spesso hanno bisogno di una versione di debug di un programma, può essere utile fare un pacchetto di debug. I programmi che fanno parte dell'infrastruttura di base, come ad esempio Apache e il server X sono anche dei buoni candidati per i pacchetti di debug.
Alcuni pacchetti di debug possono contenere un completo e particolare
versione di debug compilata di una libreria o di altro binario, ma la
maggior parte di loro può risparmiare spazio e tempo di compilazione
contenendo invece simboli di debug separati che gdb è in
grado di trovare e caricare al volo quando si effettua il debug di un
programma o di una libreria. La convenzione in Debian è quella di mantenere
questi simboli in
/usr/lib/debug/
, dove
path
path
è il percorso al file eseguibile o alla
libreria. Ad esempio, i simboli di debug per
/usr/bin/foo
vanno in
/usr/lib/debug/usr/bin/foo
e simboli di debug per
/usr/lib/libfoo.so.1
vanno in
/usr/lib/debug/usr/lib/libfoo.so.1
.
I simboli di debug possono essere estratti da un file oggetto usando objcopy - only-keep-debug. Successivamente il file oggetto può essere spogliato e objcopy - add-gnu-debuglink è utilizzato per specificare il percorso del file di simboli di debug. objcopy(1) spiega nel dettaglio come funziona questo processo.
Il comando dh_strip in debhelper
supporta la creazione di pacchetti di
debug e può prendersi cura per voi di utilizzare objcopy
per separare i simboli di debug. Se il pacchetto utilizza debhelper
, tutto quello che dovete fare è
chiamare dh_strip - DBG-package = libfoo-dbg, ed
aggiungere una voce al debian/control
per il pacchetto
di debug.
Si noti che il pacchetto di debug dovrebbe dipendere dal pacchetto per il quale fornisce i simboli di debug e questa dipendenza dovrebbe essere versionata. Per esempio:
Depends: libfoo (= ${binary:Version})
Un metapacchetto è un pacchetto per lo più vuoto che rende facile installare
un insieme coerente di pacchetti che possono evolvere nel tempo. Realizza
ciò creando una dipendenza per tutti i pacchetti dell'insieme. Grazie alla
potenza di APT, il maintainer del metapacchetto può sistemare le dipendenze
e il sistema dell'utente otterrà automaticamente i pacchetti
supplementari. I pacchetti eliminati che sono stati installati
automaticamente verranno contrassegnati come candidati alla rimozione (e
saranno anche rimossi automaticamente da
aptitude). gnome
e linux-image-amd64
sono due esempi
di metapacchetti (compilati dai pacchetti sorgente meta-gnome2
e linux-latest
).
La descrizione lunga del metapacchetto deve documentare chiaramente il suo scopo in modo che l'utente sappia che cosa si perderà se rimuovono il pacchetto. È raccomandato essere chiari sulle conseguenze. Ciò è particolarmente importante per i metapacchetti che vengono installati durante l'installazione iniziale e che non sono stati installati esplicitamente dall'utente. Questi tendono ad essere importanti per garantire regolari aggiornamenti del sistema e l'utente dovrebbe essere disincentivato dal disinstallarli in modo da evitare potenziali rotture.
[5] Non possiamo impedire agli autori originali di cambiare il tarball che
distribuiscono senza anche incrementare il numero di versione, quindi non ci
può essere alcuna garanzia che in qualsiasi momento un tarball puro sia
identico a quello di upstream attualmente in
distribuzione. Tutto ciò che ci si può aspettare è che sia identico a
qualcosa che l'autore originale una volta ha
distribuito. Se una differenza dovesse emergere in seguito (ad esempio, se
l'upstream si accorgesse che non stava usando la massima compressione nella
distribuzione originale e dunque di comprimerlo nuovamente con
gzip), semplicemente non è una buona cosa. Poiché non vi
è alcun buon modo per caricare un nuovo
.orig.tar.{gz,bz2,xz}
per la stessa versione, non c'è
nemmeno alcuna indicazione se trattare questa situazione come un bug.
[6] Come eccezione, se l'omissione di file non liberi porterebbe il sorgente a
fallire la compilazione senza assistenza da parte del Debian diff, potrebbe
essere opportuno modificare invece i file, omettendo solo le loro parti
non-free, o spiegare la situazione in un README.source
nella radice dell'albero del sorgente. Ma anche in questo caso sollecitare
l'autore originale affinché renda i componenti non liberi facilmente
separabili dal resto del sorgente.