Provided by: dpkg_1.21.9ubuntu1_amd64 bug

NOME

       dpkg-maintscript-helper - aggira limiti noti di dpkg negli script del manutentore

SINTASSI

       dpkg-maintscript-helper comando [parametro...] -- parametro-script-manut...

COMANDI E PARAMETRI

       supports comando
       rm_conffile fileconf [versione-prec [pacchetto]]
       mv_conffile vecchio-fileconf nuovo-fileconf [versione-prec [pacchetto]]
       symlink_to_dir percorso vecchia-destinaz [versione-prec [pacchetto]]
       dir_to_symlink percorso nuova-destinaz [versione-prec [pacchetto]]

DESCRIZIONE

       Questo programma è progettato per essere eseguito dall'interno di script dei manutentori
       per effettuare alcuni compiti che dpkg 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 (preinst, postinst, prerm, postrm). 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 DPKG_MAINTSCRIPT_NAME e sugli argomenti per gli
       script dei manutentori che devono essere passati dopo un doppio trattino.

PARAMETRI COMUNI

       versione-prec
           Definisce la più recente versione del pacchetto il cui aggiornamento dovrebbe attivare
           l'operazione. È importante calcolare correttamente il valore di versione-prec in modo
           che le operazioni siano effettuate in modo corretto anche se l'utente ha ricompilato
           il pacchetto con una versione locale. Se versione-prec è 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,
           versione-prec 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 2.0-1 di un
           pacchetto, versione-prec dovrebbe essere impostata a 2.0-1~. Ciò farà sì che il file
           di configurazione sia rimosso anche se l'utente ha ricompilato la versione precedente
           1.0-1 come 1.0-1local1. Oppure un pacchetto che passa un percorso da un collegamento
           simbolico (fornito nella versione 1.0-1) ad una directory (fornita nella versione
           2.0-1), ma che effettua l'effettivo cambiamento nello script del manutentore nella
           versione 3.0-1, dovrebbe impostare versione-prec a 3.0-1~.

       pacchetto
           The package name owning the pathname(s).  When the package is “Multi-Arch: same” this
           parameter must include the architecture qualifier, otherwise it should not usually
           include the architecture qualifier (as it would disallow cross-grades, or switching
           from being architecture specific to architecture all or vice versa).  If the parameter
           is empty or omitted, the DPKG_MAINTSCRIPT_PACKAGE and DPKG_MAINTSCRIPT_ARCH
           environment variables (as set by dpkg when running the maintainer scripts) will be
           used to generate an arch-qualified package name.

       --  Tutti i parametri degli script dei manutentori devono essere passati al programma dopo
           --.

COMPITI RELATIVI AI FILE DI CONFIGURAZIONE

       Quando aggiorna un pacchetto, dpkg non rimuoverà automaticamente un file di configurazione
       (un file di configurazione per il quale dpkg 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 dpkg-maintscript-helper può essere usato per implementare in
       modo pulito la cancellazione e lo spostamento di file di configurazione all'interno di
       script dei manutentori.

   Rimozione di un file di configurazione
       Note: This can be replaced in most cases by the "remove-on-upgrade" flag in
       DEBIAN/conffiles (since dpkg 1.20.6), see deb-conffiles(5).

       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
       preinst, postinst e postrm.

            dpkg-maintscript-helper rm_conffile \
               conffile prior-version package -- "$@"

       fileconf è il nome del file di configurazione da rimuovere.

       Attuale implementazione: in preinst, controlla se il file di configurazione è stato
       modificato e lo rinomina in fileconf.dpkg-remove (se non modificato) o
       fileconf.dpkg-backup (se modificato). In postinst, quest'ultimo file viene rinominato in
       fileconf.dpkg-bak e mantenuto per riferimento dato che contiene le modifiche dell'utente
       ma il primo viene rimosso. Se l'aggiornamento del pacchetto fallisce, postrm reinstalla il
       file di configurazione originale. Durante l'eliminazione completa, postrm elimina anche il
       file .dpkg-bak fino ad allora preservato.

   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 preinst, tuttavia ciò avrebbe come risultato
       che dpkg 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 preinst, postinst e postrm.

            dpkg-maintscript-helper mv_conffile \
               old-conffile new-conffile prior-version package -- "$@"

       vecchio-fileconf e nuovo-fileconf sono il nome vecchio e quello nuovo del file di
       configurazione da rinominare.

       Attuale implementazione: preinst controlla se il file di configurazione è stato
       modificato; se lo è stato viene lasciato al suo posto altrimenti viene rinominato in
       vecchio-fileconf.dpkg-remove. Durante la configurazione, postinst rimuove vecchio-
       fileconf.dpkg-remove e rinomina vecchio-fileconf in nuovo-fileconf se vecchio-fileconf è
       ancora disponibile. In caso di aggiornamento o installazione falliti, postrm rinomina
       vecchio-fileconf.dpkg-remove nuovamente in vecchio-fileconf, se necessario.

CAMBIAMENTI A COLLEGAMENTI SIMBOLICI E DIRECTORY

       Quando si aggiorna un pacchetto, dpkg non modifica automaticamente un collegamento
       simbolico in una directory o viceversa. Le retrocessioni di versione non sono supportate e
       il percorso verrà lasciato come è.

   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 preinst, 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 preinst, postinst e postrm.

            dpkg-maintscript-helper symlink_to_dir \
               pathname old-target prior-version package -- "$@"

       percorso è il nome assoluto del vecchio collegamento simbolico (il percorso sarà una
       directory al termine dell'installazione) e vecchia-destinaz è il nome della destinazione
       del vecchio collegamento simbolico percorso. Può essere sia assoluto sia relativo alla
       directory che contiene percorso.

       Attuale implementazione: preinst controlla se il collegamento simbolico esiste e punta a
       vecchia-destinaz, se non è così allora viene lasciato al suo posto, altrimenti viene
       rinominato in percorso.dpkg-backup. Durante la configurazione postinst rimuove
       percorso.dpkg-backup se questo è ancora un collegamento simbolico. In caso di
       aggiornamento o installazione falliti, postrm rinomina percorso.dpkg-backup nuovamente in
       percorso se necessario.

   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 preinst, 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 preinst, postinst e postrm.

            dpkg-maintscript-helper dir_to_symlink \
               pathname new-target prior-version package -- "$@"

       percorso è il nome assoluto della vecchia directory (il percorso sarà un collegamento
       simbolico al termine dell'installazione) e nuova-destinaz è il nome del nuovo collegamento
       simbolico percorso. Può essere sia assoluto sia relativo alla directory che contiene
       percorso.

       Attuale implementazione: preinst 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 percorso.dpkg-backup e
       viene creata una nuova directory vuota chiamata percorso marcata con un file in modo che
       dpkg possa tenerne traccia. Durante la configurazione postinst finisce il passaggio se
       percorso.dpkg-backup è ancora una directory e percorso è 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 nuova-
       destinaz/, sostituisce la directory contrassegnata percorso ora vuota con un collegamento
       simbolico a nuova-destinaz e rimuove percorso.dpkg-backup. in caso di aggiornamento o
       installazione falliti, postrm rinomina percorso.dpkg-backup nuovamente in percorso se
       necessario.

INTEGRAZIONE NEI PACCHETTI

       Quando si usa uno strumento di aiuto alla pacchettizzazione, controllare se ha
       l'integrazione nativa con dpkg-maintscript-helper, che può rendere la vita più semplice.
       Vedere ad esempio dh_installdeb(1).

       Dato che dpkg-maintscript-helper viene usato in preinst, il suo uso incondizionato
       richiede una pre-dipendenza per assicurare che sia stata già spacchettata la versione
       richiesta di dpkg. La versione richiesta dipende dal comando usato: per rm_conffile e
       mv_conffile è 1.15.7.2, per symlink_to_dir e dir_to_symlink è 1.17.14:

        Pre-Depends: dpkg (>= 1.17.14)

       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 dpkg attualmente installata:

            if dpkg-maintscript-helper supports command; then
               dpkg-maintscript-helper command ...
            fi

       Il comando supports restituisce 0 in caso di successo e 1 altrimenti. Il comando supports
       controlla se le variabili d'ambiente impostate da dpkg e richiesta dallo script sono
       presenti e considera un fallimento se l'ambiente non è sufficiente.

AMBIENTE

       DPKG_ROOT
           If set, it will be used as the filesystem root directory.

       DPKG_ADMINDIR
           If set, it will be used as the dpkg data directory.

       DPKG_COLORS
           Sets the color mode (since dpkg 1.19.1).  The currently accepted values are: auto
           (default), always and never.

VEDERE ANCHE

       dh_installdeb(1).