***************************************************** * GENERATED FILE, DO NOT EDIT * * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * ***************************************************** This file was generated by po4a(7). Do not store it (in VCS, for example), but store the PO file used as source file by po4a-translate. In fact, consider this as a binary, and the PO file as a regular .c file: If the PO get lost, keeping this translation up-to-date will be harder. =encoding UTF-8 =head1 NOME dpkg-maintscript-helper - aggira limiti noti di dpkg negli script del manutentore =head1 SINTASSI B I [I...] B<--> I... =head1 COMANDI E PARAMETRI =over =item B I =item B I [I [I]] =item B I I [I [I]] =item B I I [I [I]] =item B I I [I [I]] =back =head1 DESCRIZIONE Questo programma è progettato per essere eseguito dall'interno di script dei manutentori per effettuare alcuni compiti che B non può (ancora) gestire in modo nativo a causa di decisioni progettuali oppure per limitazioni attuali. Molti di questi compiti richiedono azioni coordinate da parte di diversi script dei manutentori (B, B, B, B). Per evitare sbagli basta mettere la stessa chiamata in tutti gli script e il programma adatterà automaticamente il suo comportamento sulla base della variabile d'ambiente B e sugli argomenti per gli script dei manutentori che devono essere passati dopo un doppio trattino. =head1 PARAMETRI COMUNI =over =item I Definisce la più recente versione del pacchetto il cui aggiornamento dovrebbe attivare l'operazione. È importante calcolare correttamente il valore di I in modo che le operazioni siano effettuate in modo corretto anche se l'utente ha ricompilato il pacchetto con una versione locale. Se I è vuota o viene omessa, allora l'operazione viene tentata ad ogni aggiornamento (notare: è più sicuro fornire la versione e far sì che l'operazione venga tentata una sola volta). Se il file di configurazione non è stato fornito per diverse versioni, e si sta ora cercando di modificare gli script del manutentore per ripulire il file obsoleto, I dovrebbe essere basata sulla versione del pacchetto che si sta preparando ora, non sulla prima versione del pacchetto a cui mancava il file di configurazione. Ciò è vero similmente per tutte le altre azioni. Per esempio, per un file di configurazione rimosso nella versione B<2.0-1> di un pacchetto, I dovrebbe essere impostata a B<2.0-1~>. Ciò farà sì che il file di configurazione sia rimosso anche se l'utente ha ricompilato la versione precedente B<1.0-1> come B<1.0-1local1>. Oppure un pacchetto che passa un percorso da un collegamento simbolico (fornito nella versione B<1.0-1>) ad una directory (fornita nella versione B<2.0-1>), ma che effettua l'effettivo cambiamento nello script del manutentore nella versione B<3.0-1>, dovrebbe impostare I a B<3.0-1~>. =item B The package name owning the pathname(s). When the package is “Multi-Arch: same” this parameter must include the architecture qualifier, otherwise it should B usually include the architecture qualifier (as it would disallow cross-grades, or switching from being architecture specific to architecture B or vice versa). If the parameter is empty or omitted, the B and B environment variables (as set by B when running the maintainer scripts) will be used to generate an arch-qualified package name. =item B<--> Tutti i parametri degli script dei manutentori devono essere passati al programma dopo B<-->. =back =head1 COMPITI RELATIVI AI FILE DI CONFIGURAZIONE Quando aggiorna un pacchetto, B non rimuoverà automaticamente un file di configurazione (un file di configurazione per il quale B dovrebbe preservare i cambiamenti dell'utente) se non è presente nella versione più nuova. Ci sono due ragioni principali per questo comportamento. La prima è che il file di configurazione potrebbe essere stato tolto per sbaglio e la successiva versione potrebbe ripristinarlo e gli utenti non vorrebbero vedere le proprie modifiche buttate al vento. La seconda è di permettere ai pacchetti di transitare file da un file di configurazione mantenuto da dpkg a un file mantenuto dagli script del manutentore del pacchetto, solitamente con uno strumento come debconf o ucf. Ciò significa che se un pacchetto deve rinominare o rimuovere un file di configurazione, deve farlo esplicitamente e B può essere usato per implementare in modo pulito la cancellazione e lo spostamento di file di configurazione all'interno di script dei manutentori. =head2 Rimozione di un file di configurazione Note: This can be replaced in most cases by the C flag in F (since dpkg 1.20.6), see L. Se un file di configurazione viene completamente rimosso, dovrebbe essere rimosso dal disco a meno che l'utente non l'abbia modificato. Se ci sono modifiche locali, queste dovrebbero essere preservate. Se l'aggiornamento del pacchetto fallisce, il file di configurazione appena reso obsoleto non dovrebbe sparire. Tutto ciò è implementato mettendo il seguente frammento shell negli script del manutentore B, B e B. =over Z<> dpkg-maintscript-helper rm_conffile \ I I I -- "$@" =back I è il nome del file di configurazione da rimuovere. Attuale implementazione: in B, controlla se il file di configurazione è stato modificato e lo rinomina in IB<.dpkg-remove> (se non modificato) o IB<.dpkg-backup> (se modificato). In B, quest'ultimo file viene rinominato in IB<.dpkg-bak> e mantenuto per riferimento dato che contiene le modifiche dell'utente ma il primo viene rimosso. Se l'aggiornamento del pacchetto fallisce, B reinstalla il file di configurazione originale. Durante l'eliminazione completa, B elimina anche il file B<.dpkg-bak> fino ad allora preservato. =head2 Rinominare un file di configurazione Se un file di configurazione viene spostato da una posizione ad un'altra, è necessario assicurarsi di spostare qualsiasi modifica fatta dall'utente. Questo può sembrare a prima vista un semplice cambiamento dello script B, tuttavia ciò avrebbe come risultato che B chiederebbe all'utente di approvare le modifiche al file di configurazione anche se egli non ne è responsabile. Un cambio di nome pulito può essere implementato mettendo il seguente frammento shell negli script del manutentore B, B e B. =over Z<> dpkg-maintscript-helper mv_conffile \ I I I I -- "$@" =back I e I sono il nome vecchio e quello nuovo del file di configurazione da rinominare. Attuale implementazione: B controlla se il file di configurazione è stato modificato; se lo è stato viene lasciato al suo posto altrimenti viene rinominato in IB<.dpkg-remove>. Durante la configurazione, B rimuove IB<.dpkg-remove> e rinomina I in I se I è ancora disponibile. In caso di aggiornamento o installazione falliti, B rinomina IB<.dpkg-remove> nuovamente in I, se necessario. =head1 CAMBIAMENTI A COLLEGAMENTI SIMBOLICI E DIRECTORY Quando si aggiorna un pacchetto, B non modifica automaticamente un collegamento simbolico in una directory o viceversa. Le retrocessioni di versione non sono supportate e il percorso verrà lasciato come è. =head2 Passare da un collegamento simbolico ad una directory Se si passa da un collegamento simbolico ad una directory reale, è necessario assicurarsi prima dello spacchettamento che il collegamento simbolico venga rimosso. Ciò può sembrare a prima vista una semplice modifica allo script B, tuttavia ciò risulterebbe in alcuni problemi nel caso di personalizzazioni locali dell'amministratore sul collegamento simbolico o in caso di retrocessione del pacchetto. Un cambio di nome pulito può essere implementato mettendo il seguente frammento shell negli script del manutentore B, B e B. =over Z<> dpkg-maintscript-helper symlink_to_dir \ I I I I -- "$@" =back I è il nome assoluto del vecchio collegamento simbolico (il percorso sarà una directory al termine dell'installazione) e I è il nome della destinazione del vecchio collegamento simbolico I. Può essere sia assoluto sia relativo alla directory che contiene I. Attuale implementazione: B controlla se il collegamento simbolico esiste e punta a I, se non è così allora viene lasciato al suo posto, altrimenti viene rinominato in IB<.dpkg-backup>. Durante la configurazione B rimuove IB<.dpkg-backup> se questo è ancora un collegamento simbolico. In caso di aggiornamento o installazione falliti, B rinomina IB<.dpkg-backup> nuovamente in I se necessario. =head2 Passare da una directory a un collegamento simbolico Se si passa da una directory reale a un collegamento simbolico, è necessario assicurarsi prima dello spacchettamento che la directory venga rimossa. Ciò può sembrare a prima vista una semplice modifica allo script B, tuttavia ciò risulterebbe in alcuni problemi nel caso in cui la directory contenga file di configurazione, nomi di percorso di proprietà di altri pacchetti, nomi di percorso creati localmente, oppure in caso di retrocessione del pacchetto. Un passaggio pulito può essere implementato mettendo il seguente frammento shell negli script del manutentore B, B e B. =over Z<> dpkg-maintscript-helper dir_to_symlink \ I I I I -- "$@" =back I è il nome assoluto della vecchia directory (il percorso sarà un collegamento simbolico al termine dell'installazione) e I è il nome del nuovo collegamento simbolico I. Può essere sia assoluto sia relativo alla directory che contiene I. Attuale implementazione: B controlla se la directory esiste, non contiene file di configurazione, percorsi di proprietà di altri pacchetti o percorsi creati localmente; se non è così è lasciata al suo posto, altrimenti viene rinominata in IB<.dpkg-backup> e viene creata una nuova directory vuota chiamata I marcata con un file in modo che dpkg possa tenerne traccia. Durante la configurazione B finisce il passaggio se IB<.dpkg-backup> è ancora una directory e I è la directory contrassegnata; rimuove il file che contrassegna la directory, muove i file appena creati all'interno della directory contrassegnata nella destinazione del collegamento simbolico I/, sostituisce la directory contrassegnata I ora vuota con un collegamento simbolico a I e rimuove IB<.dpkg-backup>. in caso di aggiornamento o installazione falliti, B rinomina IB<.dpkg-backup> nuovamente in I se necessario. =head1 INTEGRAZIONE NEI PACCHETTI Quando si usa uno strumento di aiuto alla pacchettizzazione, controllare se ha l'integrazione nativa con B, che può rendere la vita più semplice. Vedere ad esempio B(1). Dato che B viene usato in B, il suo uso incondizionato richiede una pre-dipendenza per assicurare che sia stata già spacchettata la versione richiesta di B. La versione richiesta dipende dal comando usato: per B e B è 1.15.7.2, per B e B è 1.17.14: =over Pre-Depends: dpkg (>= 1.17.14) =back In molti casi però l'operazione effettuata dal programma non è critica per il pacchetto e invece di usare una pre-dipendenza si può chiamare il programma solo se si sa che il comando richiesto è supportato dalla versione di B attualmente installata: =over Z<> if dpkg-maintscript-helper supports I; then dpkg-maintscript-helper I ... fi =back Il comando B restituisce 0 in caso di successo e 1 altrimenti. Il comando B controlla se le variabili d'ambiente impostate da dpkg e richiesta dallo script sono presenti e considera un fallimento se l'ambiente non è sufficiente. =head1 AMBIENTE =over =item B If set, it will be used as the filesystem root directory. =item B If set, it will be used as the B data directory. =item B Sets the color mode (since dpkg 1.19.1). The currently accepted values are: B (default), B and B. =back =head1 VEDERE ANCHE B(1).