Capitolo 8. Aggiornamento del pacchetto

# Capitolo 8. Aggiornamento del pacchetto

È 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.

Una volta rilasciato un pacchetto, ci sarà presto bisogno di aggiornarlo.

## 8.1. Nuova revisione Debian

Si supponga che sia stato compilato il bug report `#654321` per il pacchetto creato, e che questo descriva un problema che si può risolvere. Qui è descritto come creare una nuova revisione del pacchetto Debian:

- Se la modifica deve essere registrata come una nuova patch, si seguano queste istruzioni:

  - `dquilt new `bugname.patch`` per impostare il nome della patch;

  - `dquilt add `buggy-file`` per indicare i file modificati;

  - Correggere il problema evidenziato dal bug report nel pacchetto sorgente;

  - `dquilt refresh` per registrare le modifiche in ``bugname.patch``;

  - `dquilt header -e` per aggiungere una descrizione;

- Se la modifica è un aggiornamento ad una patch esistente, si seguano queste istruzioni:

  - `dquilt pop `foo.patch`` per richiamare la patch ``foo.patch`` esistente;

  - Correggere il problema nella vecchia patch ``foo.patch``;

  - `dquilt refresh` per aggiornare ``foo.patch``;

  - `dquilt header -e` per aggiornarne la descrizione;

  - `while dquilt push; do dquilt refresh; done` per applicare tutte le patch mentre si sta rimuovendo il fuzz;

- Aggiungere una nuova revisione in cima al file di `changelog` Debian, per esempio con `dch -i`, o esplicitamente con `dch -v `version`-`revision`` e poi inserire i commenti utilizzando l'editor preferito. [76]

- Includere nella nuova voce del changelog una breve descrizione del problema e della relativa soluzione, seguita da `Closes: #654321`. In questo modo, il report del problema verrà automaticamente chiuso dal programma di manutenzione dell'archivio Debian nel momento stesso in cui il pacchetto viene accettato.

- Si ripetano questi passaggi per risolvere ulteriori problemi e si ricordi nel frattempo di aggiornare il file Debian di `changelog` con `dch` a seconda della necessità.

- Si ripetano i passi fatti in Sezione 6.1, «(ri)Creazione completa», Capitolo 7, Controllare il pacchetto per errori.

- Quando si è soddisfatti, si può cambiare il valore del campo distribuzione nel file `changelog` da `UNRELEASED` a `unstable` (o anche `experimental`).[77]

- Caricare i pacchetti come Capitolo 9, Caricamento del pacchetto. La differenza è che questa volta, l'archivio del sorgente originale non sarà incluso, dal momento che non è stato modificato e già esiste nell'archivio Debian.

Un caso complicato può verificarsi quando si crea un pacchetto locale per sperimentare la pacchettizzazione prima di caricare la versione normale nell'archivio ufficiale, ad esempio ``1.0.1`-`1``. Per facilitare gli aggiornamenti è consigliabile creare una voce con la stringa della versione come ``1.0.1`-`1~rc1`` nel file `changelog`. Per il pacchetto ufficiale si può riordinare il file `changelog` consolidando la modifiche locali in una singola voce. Si veda Sezione 2.6, «Nome e versione del pacchetto» per l'ordine delle stringhe di versione.

## 8.2. Controllo della nuova distribuzione

Quando si stanno preparando i pacchetti della nuova release per l'archivio Debian, bisogna controllare prima la nuova release del pacchetto originale.

Si comincia leggendo i file originali `changelog`, `NEWS`, e qualsiasi altra documentazione che possa essere stata rilasciata con la nuova versione.

Successivamente si controllano i cambiamenti tra i vecchi sorgenti originali e quelli nuovi, come mostrato in seguito, alla ricerca di qualsiasi modifica sospetta:

    $ diff -urN foo-oldversion foo-newversion

I cambiamenti effettuati ad alcuni file generati automaticamente dagli Autotools come `missing`, `aclocal.m4`, `config.guess`, `config.h.in`, `config.sub`, `configure`, `depcomp`, `install-sh`, `ltmain.sh`, e `Makefile.in` possono essere ignorati. Possono anzi venire cancellati prima di eseguire diff per controllare i sorgenti.

## 8.3. Nuova distribuzione

Se un pacchetto ``foo`` è stato impacchettato correttamente nei nuovi formati `3.0 (native)` o `3.0 (quilt)`, si rende necessario impacchettare anche la versione originale muovendo la directory `debian` nella nuova sorgente. Questo può essere fatto eseguendo `tar xvzf /`path`/`to`/`foo`_`oldversion`.debian.tar.gz` nella nuova directory sorgente scompattata. [78] Ovviamente bisognerà effettuare alcuni passaggi:

- Creare una copia dei sorgenti originali nel file `foo_`newversion`.orig.tar.gz`.

- Aggiornare il file di `changelog` Debian con `dch -v `newversion`-`1``.

  - Aggiungere una voce che dica `New upstream release`.

  - Descrivere brevemente i cambiamenti nella nuova distribuzione che correggono i bug riportati e ne chiudono altri aggiungendo `Closes: #`numero_bug``.

  - Descrivere brevemente i cambiamenti nella nuova distribuzione, effettuati dal manutentore, che correggono i bug riportati e li chiudono aggiungendo `Closes: #`numero_bug``.

- `while dquilt push; do dquilt refresh; done` per applicare tutte le patch mentre si sta rimuovendo il fuzz.

Se la patch/merge non è stata applicata in maniera corretta, si controlli la situazione (gli indizi vengono lasciati nei file `.rej`).

- Se una patch applicata ai sorgenti è stata integrata nei sorgenti originali,

  - si rimuova con `dquilt delete`.

- Se una patch applicata alla sorgente è andata in conflitto con i nuovi cambiamenti nei sorgenti originali,

  - si esegua `dquilt push -f` per applicare le vecchie patch forzando gli scarti nel file ``baz`.rej`.

  - Modificare manualmente il file ``baz`` per applicare gli effetti desiderati presenti nel file ``baz`.rej`.

  - `dquilt refresh` per aggiornare la patch.

- Ritornare alla procedura `while dquilt push; do dquilt refresh; done`.

Questo processo può essere automatizzato utilizzando il comando uupdate(1) come segue:

    $ apt-get source foo
    ...
    dpkg-source: info: extracting foo in foo-oldversion
    dpkg-source: info: unpacking foo_oldversion.orig.tar.gz
    dpkg-source: info: applying foo_oldversion-1.debian.tar.gz
    $ ls -F
    foo-oldversion/
    foo_oldversion-1.debian.tar.gz
    foo_oldversion-1.dsc
    foo_oldversion.orig.tar.gz
    $ wget http://example.org/foo/foo-newversion.tar.gz
    $ cd foo-oldversion
    $ uupdate -v newversion ../foo-newversion.tar.gz
    $ cd ../foo-newversion
    $ while dquilt push; do dquilt refresh; done
    $ dch
    ... document changes made

Se si imposta il file `debian/watch` come descritto in Sezione 5.21, «`watch`», si può saltare il comando wget. Basterà eseguire uscan(1) nella directory ``foo`-`oldversion`` al posto del comando uupdate. Questo cercherà auto-magicamente i sorgenti corretti, li scaricherà ed eseguirà il comando uupdate. [79]

Si possono rilasciare questi sorgenti aggiornati ripetendo ciò che si è fatto in Sezione 6.1, «(ri)Creazione completa», Capitolo 7, Controllare il pacchetto per errori, ed Capitolo 9, Caricamento del pacchetto.

## 8.4. Aggiornare lo stile di pacchettizzazione

L'aggiornamento dello stile del pacchetto non è una attività obbligatoria nel processo di aggiornamento di quest'ultimo. Tuttavia facendo ciò si può sfruttare appieno la capacità del moderno sistema `debhelper` ed il formato sorgente `3.0`. [80]

- Se per qualsiasi motivo c'è la necessità di aggiungere file di template cancellati, si può eseguire nuovamente il comando dh_make nella stessa directory del sorgente del pacchetto Debian con l'opzione `--addmissing`. Fatto questo si potrà modificarlo di conseguenza.

- Se il pacchetto non è stato aggiornato per utilizzare la sintassi v7+ di dh del pacchetto `debhelper` per il file `debian/rules`, si deve effettuare un aggiornamento per poter usare dh. Si aggiorni di conseguenza anche il file `debian/control`.

- Se si desidera aggiornare il file `rules` creato con il meccanismo di inclusione "Common Debian Build System" (`cdbs`) del `Makefile` con la sintassi dh, si veda più avanti per capire le variabili di configurazione `DEB_*`.

  - copia locale di `/usr/share/doc/cdbs/cdbs-doc.pdf.gz`

  - The Common Debian Build System (CDBS), FOSDEM 2009

- Se si ha un pacchetto sorgente nella versione `1.0` senza il file ``foo`.diff.gz`, si può aggiornare al nuovo formato sorgente `3.0 (native)` creando il file `debian/source/format` contenente `3.0 (native)`. Gli altri file `debian/*` possono essere semplicemente copiati.

- Se si ha un pacchetto sorgente nella versione `1.0` con il file ``foo`.diff.gz`, si può aggiornare al nuovo formato sorgente `3.0 (quilt)` creando il file `debian/source/format` contenente `3.0 (quilt)`. Gli altri file `debian/*` possono essere semplicemente copiati. Se necessario, si importi il file `big.diff` generato dal comando `filterdiff -z -x '*/debian/*' `foo`.diff.gz > big.diff` nel sistema quilt.[81]

- Si nel pacchetto è stato utilizzato un altro sistema di patch come `dpatch`, `dbs`, o `cdbs` con `-p0`, `-p1`, o `-p2`, lo si può convertire con il comando `quilt` utilizzando `deb3` presente su http://bugs.debian.org/581186.

- Se il pacchetto è stato creato con il comando dh con l'opzione `--with quilt` o con i comandi dh_quilt_patch e dh_quilt_unpatch, si rimuovano i file prodotti e li si sostituisca usando il nuovo formato dei sorgenti `3.0 (quilt)`.

Bisogna controllare DEP - Debian Enhancement Proposals e adottare le proposte ACCEPTED.

Ci sarà anche bisogno di eseguire ulteriori operazioni descritte in Sezione 8.3, «Nuova distribuzione».

## 8.5. Conversione UTF-8

Se i documenti originali sono codificato con vecchi schemi di codifica, è buona norma convertirli in UTF-8.

- Utilizzare iconv(1) per convertire le codifiche dei file di testo.

      iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt

- Utilizzare w3m(1) per convertire da file HTML a file di testo UTF-8. Ci si assicuri di utilizzarlo in un ambiente con localizzazione UTF-8.

      LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \
              -cols 70 -dump -no-graph -T text/html \
              < foo_in.html > foo_out.txt

## 8.6. Note per l'aggiornamento dei pacchetti

Vengono qui presentate alcune note per l'aggiornamento dei pacchetti:

- Si preservino le vecchie voci del `changelog` (sembra ovvio, ma a volte si sono verificati problemi per aver scritto `dch` mentre si sarebbe dovuto scrivere `dch -i`.)

- Cambiamenti preesistenti devono essere ricontrollati; si scarti tutto ciò che è stato incorporato in upstream (in una forma o nell'altra) e ci si ricordi di mantenere tutto quello che non è stato incorporato dall'upstream, a meno che non ci sia una buona ragione per non farlo.

- Se è stato fatto qualsiasi cambiamento nel sistema di costruzione del pacchetto (sperabilmente ce se ne renderà conto controllando i cambiamenti dall'originale) allora si aggiorni il file `debian/rules` e le dipendenze di `debian/control` se necessario.

- Si controlli nel Debian Bug Tracking System (BTS) se qualcuno ha reso disponibili delle patch ai bug che sono attualmente aperti.

- Si controlli il contenuto del file `.changes` per essere sicuri che si stia caricando per la distribuzione corretta, le risoluzioni ai bug vengono listate nel campo `Closes`, i campi `Maintainer` e `Changed-By` corrispondono, il file è firmato con GPG, ecc.

[76] Per impostare la data nel formato corretto, si usi `LANG=C date -R`.

[77] Se si utilizza il comando `dch -r` per effettuare quest'ultima modifica, ci si assicuri che l'editor salvi il file con il nome `changelog`.

[78] Se un pacchetto ``foo`` è stato pacchettizzato nel vecchio formato `1.0`, si deve invece eseguire `zcat /`path`/`to`/`foo`_`oldversion`.diff.gz|patch -p1` nella nuova directory sorgente scompattata.

[79] Se il comando uscan scarica il sorgente aggiornato ma non esegue il comando uupdate, si può modificare il file `debian/watch` inserendo `debian uupdate` alla fine dell'URL.

[80] Se il proprio sponsor o altri manutentori non ritengono sia necessario aggiornare lo stile del pacchetto, allora non vale la pena perderci molto tempo. Ci sono cose più importanti da fare.

[81] È possibile dividere il file `big.diff` in tante piccole patch incrementali utilizzando il comando splitdiff.

Capitolo 7. Controllare il pacchetto per errori |  | Capitolo 9. Caricamento del pacchetto