Differences between revisions 3 and 14 (spanning 11 versions)
Revision 3 as of 2013-05-10 19:33:10
Size: 5516
Comment: sync with English master
Revision 14 as of 2020-03-06 16:00:23
Size: 12706
Comment: sync with English master v. 45
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[PackagingWithGit|English]] - Italiano-~ ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[de/PackagingWithGit|Deutsch]] - [[PackagingWithGit|English]] - [[id/PackagingWithGit|Indonesian]] - Italiano-~
Line 8: Line 8:
{i} Notare che questa è solamente una guida introduttiva molto generica. La documentazione ufficiale completa è disponibile nel pacchetto DebianPkg:git-buildpackage (vedere [[https://honk.sigxcpu.org/piki/projects/git-buildpackage/|la documentazione online]]). {{{#!wiki tip
Notare che questa è solamente una guida introduttiva molto generica. La documentazione ufficiale completa è disponibile nel pacchetto DebianPkg:git-buildpackage (vedere [[https://honk.sigxcpu.org/piki/projects/git-buildpackage/|la documentazione online]]).
Line 13: Line 14:

Questa pagina descrive il flusso di lavoro usando i comandi del pacchetto git-buildpackage. In alternativa esiste anche [[PackagingWithGit/GitDpm|git-dpm]].
}}}

{{{#!wiki note
Questa pagina descrive il flusso di lavoro usando i comandi del pacchetto git-buildpackage. In alternativa esiste anche [[PackagingWithGit/GitDpm|git-dpm]] e DebianPackage:gitpkg.
}}}
== Metodi di importazione dalla fonte originale a monte ==
Ci sono due modi principali di importare il codice originale in un repository debianizzato:

 * Si possono importare gli archivi tar dei rilasci originali in un repository specifico per Debian. Ciò crea un commit per ogni rilascio. Viene generalmente fatto con il comando {{{gbp import-orig}}}. È il metodo più generico perché dà per scontato solamente che gli autori a monte rilascino archivi tar.
 * Se gli autori originali usando git per gestire i propri sorgenti, il repository di debianizzazione può risiedere in un ramo dell'albero principale originale a monte. Chiaramente questo funziona solo con alcuni archivi originali, ma il grande vantaggio è che la relazione tra la debianizzazione e il codice a monte è MOLTO chiara. L'applicazione di patch e i rilasci avvengono in modo più naturale. Dato che i repository APT di Debian usano ancora gli archivi tar, anche con questa configurazione è sempre necessario gestirli ma {{{pristine-tar}}} esiste proprio a questo scopo.

Esiste anche una terza opzione, che è una combinazione dei due metodi precedenti: {{{gbp import-orig --upstream-vcs-tag}}}. Ciò è utile principalmente quando l'archivio tar originale non è identico al rilascio originale, il che può avvenire ad esempio se:

 * l'archivio tar è stato reimpacchettato (per rimuovere pezzi non-DFSG, ad esempio)
 * lo script usato dagli autori a monte per creare gli archivi tar fa delle modifiche ({{{make dist}}} di autotools lo fa in alcuni progetti)

I vari pro e contro sono discussi nelle pagine seguenti:

 * http://www.eyrie.org/~eagle/journal/2013-04/001.html
 * http://joeyh.name/blog/entry/upstream_git_repositories/
 * http://www.eyrie.org/~eagle/notes/debian/git.html#combine
Line 17: Line 37:
È più facile creare la prima versione di un pacchetto fuori da Git; una volta che ciò è stato fatto si deve importare il pacchetto usando lo strumento {{{git-import-dsc}}}. La directory in cui viene invocato diventerà la directory genitrici del nuovo repository Git.

{{{
$ git-import-dsc /percorso/del/pacchetto_0.1-1.dsc

=== Importare i sorgenti originali a monte come archivio tar ===

È più facile creare la prima versione di un pacchetto fuori da Git; una volta che ciò è stato fatto si deve importare il pacchetto usando il comando {{{import-dsc}}} dello strumento {{{gbp}}}. ''In passato c'era git-import-dsc.''. La directory in cui viene invocato diventerà la directory genitrici del nuovo repository Git.

{{{
$ gbp import-dsc /percorso/del/pacchetto_0.1-1.dsc
Line 35: Line 58:
=== Usare il repository originale a monte ===
Se gli autori a monte usano già git, basta creare un ramo per la debianizzazione. Per convenzione i nomi dei rami e delle etichette sono quelli del caso precedente già visto, perciò si può creare il ramo {{{master}}} dal rilascio {{{upstream}}} e aggiungere la directory {{{debian/}}} come commit.
Line 44: Line 70:
$ git-buildpackage $ gbp buildpackage
Line 49: Line 75:
$ git-buildpackage --git-tag $ gbp buildpackage --git-tag
Line 53: Line 79:
== Gestire patch Debian ==
Lo strumento {{{gbp-pq}}} può essere usato per tenere taccia delle patch in git e per esportarle e importarle da e verso la serie quilt in {{{debian/patches}}}.
Line 54: Line 83:
Quando è disponibile una nuova versione a monte, usare lo strumento {{{git-import-orig}}} per aggiungerla al repository, in questo modo:

{{{
$ git-import-orig /percorso/della/nuova-a-monte.tar.gz -u 0.2
=== Importando il codice originale come archivi tar ===
Quando è disponibile una nuova versione a monte, usare il comando {{{import-orig}}} per aggiungerla al repository. ''In precedenza c'era {{{git-import-orig}}}.''.

==== Usando un file debian/watch (raccomandato) ====


{{{
$ gbp import-orig --uscan
}}}

==== Usando un file di archivio tar ====

{{{
$ gbp
import-orig /percorso/della/nuova-a-monte.tar.gz -u 0.2
Line 62: Line 100:


=== Usando il repository originale a monte ===

Se si sta usando il repository originale a monte, si può recuperare con {{{git fetch}}} l'etichetta del nuovo rilascio nel repository, nel ramo {{{upstream}}}. È necessario usare {{{git merge}}} per fare il merge di questo ramo in {{{master}}} e fare il commit del nuovo archivio tar con {{{pristine-tar}}}. Si può fare il rebase delle patch con {{{gbp-pq}}} e si può usare git stesso per risolvere qualsiasi conflitto che si è creato.

== Fare il merge di un ramo debian-experimental in master per sid ==

Poniamo che si abbiano i seguenti rami:

||upstream||più recente versione a monte in fase di sviluppo||
||upstream-1.5||serie 1.5 a monte, considerata stabile||
||master||ramo per creare pacchetti per sid||
||debian-experimental||ramo per creare pacchetti per experimental||

 * Si importa ogni rilascio in upstream-1.5 e si fa il merge in master
 * Si fa il merge di ogni rilascio beta (1.6~beta) in upstream e si fa il merge in debian-experimental

Ad un certo punto si vuole spostare il lavoro da debian-experimental al ramo master e rilasciarlo in unstable.

Come prima cosa è necessario assicurarsi che debian-experimental abbia tutto a posto in debian/*: forse si è fatto il commit di qualcosa in master e non lo si è scelto anche per debian-experimental. Si possono confrontare le sottogerarchie debian/ con:

{{{
git checkout master
git diff debian-experimental debian
}}}

Se necessario, riportare una a una le modifiche in debian-experimental. Il prossimo merge azzererà tutto in master e lo sostituirà con il contenuto del ramo debian-experimental. L'unica cosa che viene mantenuta è debian/changelog dato che deve riflettere la cronologia delle modifiche all'interno di sid e non deve contenere dettagli sui singoli rilasci in experimental. Ecco come farlo (assicurarsi che master sia uno spazio di lavoro pulito):

{{{
git checkout master
git clean -fd && git checkout .
git merge -s ours debian-experimental
git diff --binary debian-experimental | git apply -R --index
git reset debian/changelog
git checkout debian/changelog
git commit -m 'Merge 1.6.0~rc1 from debian-experimental' --amend
}}}

Dopo aver fatto questo, è caldamente raccomandato ispezionare il merge con gitk e con git diff prima di fare il push su alioth o qualsiasi altro sviluppatore. Ad esempio

{{{
git diff debian-experimental
}}}

invocato in master dovrebbe mostrare solo il changelog, dato che ogni altra cosa in master dovrebbe essere ora identica a debian-experimental.
Line 67: Line 151:
Line 85: Line 170:
Se si abilita pristine-tar, quando si esegue {{{git-import-dsc}}} o {{{git-import-orig}}} viene fatto il commit dei file delta in un ramo pristine-tar. quando si crea il pacchetto usando git-buildpackage, l'archivio tar esatto viene rigenerato usando pristine-tar.

L'opzione {{{--pristine-tar}}} può essere usata sia quando si usa lo strumento {{{git-import-dsc}}} sia {{{git-import-orig}}}. Quando si esegue {{{git-buildpackage}}}, si può usare l'opzione {{{--git-pristine-tar}}}.
Se si abilita pristine-tar, quando si esegue {{{git-import-dsc}}} o {{{git-import-orig}}} viene fatto il commit dei file delta in un ramo pristine-tar. quando si crea il pacchetto usando gbp buildpackage, l'archivio tar esatto viene rigenerato usando pristine-tar.

L'opzione {{{--pristine-tar}}} può essere usata sia quando si usa lo strumento {{{git-import-dsc}}} sia {{{git-import-orig}}}. Quando si esegue {{{gbp buildpackage}}}, si può usare l'opzione {{{--git-pristine-tar}}}.
Line 90: Line 175:
=== Eseguire lintian dopo la compilazione ===

Aggiungere quanto segue a ~/.gbp.conf :
{{{
postbuild = lintian -I $GBP_CHANGES_FILE && echo "Lintian OK"
}}}

=== Eseguire autopkgtest dopo la compilazione ===

Come prima cosa configurare un ambiente per adt (vedere la documentazione di autopkgtest, man adt-run)
Poi aggiungere quanto segue al proprio ~/.gbp.conf :
{{{
postbuild = adt-run --changes $GBP_CHANGES_FILE --- schroot sid-amd64-sbuild; [ $? -eq 0 -o $? -eq 8 ]
}}}

L'ultimo controllo serve a evitare fallimenti nel caso in cui non ci sono controlli da eseguire.

=== Esempio di gbp.conf ===

{{{
[DEFAULT]
builder = git-pbuilder
cleaner = fakeroot debian/rules clean
# Creare pristine-tar all'importazione
pristine-tar = True
# Eseguire lintian per controllare il pacchetto dopo la compilazione
postbuild = lintian -iIE --pedantic $GBP_CHANGES_FILE && echo "Lintian OK"""

[buildpackage]
export-dir = ../build-area/

[import-orig]
# Filtrare via file/dir non desiderati dal codice originale a monte
filter = [
    '*egg.info',
    '.bzr',
    '.hg',
    '.hgtags',
    '.svn',
    'CVS',
    '*/debian/*',
    'debian/*'
    ]
# filtrare i file dagli archivi tar passati a pristine-tar
filter-pristine-tar = True

[import-dsc]
filter = [
    'CVS',
    '.cvsignore',
    '.hg',
    '.hgignore',
    '.bzr',
    '.bzrignore',
    '.gitignore'
    ]

[dch]
# ignorare i messaggi di merge commit
git-log = --no-merges
}}}
Line 92: Line 239:
 * [[it/Alioth/Git|Usare Git su Alioth]]  * [[it/Salsa|Salsa]] - server di sviluppo collaborativo per Debian basato sul software !GitLab
Line 94: Line 241:
 * [[cowbuilder]] può essere utile  * [[cowbuilder]] e [[git-pbuilder]] possono essere utili
Line 103: Line 250:
 * [[http://people.debian.org/~debalance/packaging-with-git.html|Co-mantenere un pacchetto Debian con git, git-buildpackage e pbuilder]] di Philipp Huebner
 * [[https://gbp.sigxcpu.org/manual|Manuale di Git-buildpackage]]

Translation(s): Deutsch - English - Indonesian - Italiano


Pacchettizzazione con Git

Notare che questa è solamente una guida introduttiva molto generica. La documentazione ufficiale completa è disponibile nel pacchetto git-buildpackage (vedere la documentazione online).

Per un aiuto per la conversione di repository Subversion creati da svn-buildpackage in git, vedere la sottopagina sulla conversione da svn-buildpackage.

Si dovrebbe anche leggere le informazioni sul supporto pristine-tar più avanti.

Questa pagina descrive il flusso di lavoro usando i comandi del pacchetto git-buildpackage. In alternativa esiste anche git-dpm e gitpkg.

Metodi di importazione dalla fonte originale a monte

Ci sono due modi principali di importare il codice originale in un repository debianizzato:

  • Si possono importare gli archivi tar dei rilasci originali in un repository specifico per Debian. Ciò crea un commit per ogni rilascio. Viene generalmente fatto con il comando gbp import-orig. È il metodo più generico perché dà per scontato solamente che gli autori a monte rilascino archivi tar.

  • Se gli autori originali usando git per gestire i propri sorgenti, il repository di debianizzazione può risiedere in un ramo dell'albero principale originale a monte. Chiaramente questo funziona solo con alcuni archivi originali, ma il grande vantaggio è che la relazione tra la debianizzazione e il codice a monte è MOLTO chiara. L'applicazione di patch e i rilasci avvengono in modo più naturale. Dato che i repository APT di Debian usano ancora gli archivi tar, anche con questa configurazione è sempre necessario gestirli ma pristine-tar esiste proprio a questo scopo.

Esiste anche una terza opzione, che è una combinazione dei due metodi precedenti: gbp import-orig --upstream-vcs-tag. Ciò è utile principalmente quando l'archivio tar originale non è identico al rilascio originale, il che può avvenire ad esempio se:

  • l'archivio tar è stato reimpacchettato (per rimuovere pezzi non-DFSG, ad esempio)
  • lo script usato dagli autori a monte per creare gli archivi tar fa delle modifiche (make dist di autotools lo fa in alcuni progetti)

I vari pro e contro sono discussi nelle pagine seguenti:

Iniziare

Importare i sorgenti originali a monte come archivio tar

È più facile creare la prima versione di un pacchetto fuori da Git; una volta che ciò è stato fatto si deve importare il pacchetto usando il comando import-dsc dello strumento gbp. In passato c'era git-import-dsc.. La directory in cui viene invocato diventerà la directory genitrici del nuovo repository Git.

$ gbp import-dsc /percorso/del/pacchetto_0.1-1.dsc

Questo produrrà nell'output informazioni sul suo progresso e farà alcuni commit. In seguito, si avranno alcuni nuovi file e directory:

$ ls
pacchetto/
pacchetto_0.1-1.orig.tar.gz

Cercando nel nuovo repository si vede che git-buildpackage ha fatto quanto segue:

  • importato i file del pacchetto (ma non la directory debian/) nel ramo upstream

  • questo è stato etichettato come upstream/0.1 dove 0.1 è il numero di versione del pacchetto

  • importata la directory debian/ in master così come i file della versione originale a monte

  • etichettato l'ultimo commit come debian/0.1-1 dato che assume che il pacchetto sia finito

Usare il repository originale a monte

Se gli autori a monte usano già git, basta creare un ramo per la debianizzazione. Per convenzione i nomi dei rami e delle etichette sono quelli del caso precedente già visto, perciò si può creare il ramo master dal rilascio upstream e aggiungere la directory debian/ come commit.

Successivo lavoro di pacchettizzazione

Ora si può lavorare nel ramo master per modificare il pacchetto. Fare il commit con:

$ git commit -a

e creare il pacchetto con:

$ gbp buildpackage

Una volta prodotto un pacchetto pronto per il rilascio, lo si dovrebbe etichettare nel modo seguente:

$ gbp buildpackage --git-tag

Assicurarsi che il proprio file debian/changelog sia corretto dato che è quello che verrà usato per creare l'etichetta che si chiamerà debian/0.1-2 dove 0.1-2 è la versione Debian.

Gestire patch Debian

Lo strumento gbp-pq può essere usato per tenere taccia delle patch in git e per esportarle e importarle da e verso la serie quilt in debian/patches.

Aggiornamento ad una nuova versione originale a monte

Importando il codice originale come archivi tar

Quando è disponibile una nuova versione a monte, usare il comando import-orig per aggiungerla al repository. In precedenza c'era git-import-orig..

Usando un file debian/watch (raccomandato)

$ gbp import-orig --uscan

Usando un file di archivio tar

$ gbp import-orig /percorso/della/nuova-a-monte.tar.gz -u 0.2

dove 0.2 è il nuovo numero di versione originale a monte.

{i} Se l'archivio tar originale a monte è già nella forma nome-pacchetto_versione.orig.tar.gz (Es. pacchetto_0.2.orig.tar.gz), allota l'opzione -u non è necessaria.

Usando il repository originale a monte

Se si sta usando il repository originale a monte, si può recuperare con git fetch l'etichetta del nuovo rilascio nel repository, nel ramo upstream. È necessario usare git merge per fare il merge di questo ramo in master e fare il commit del nuovo archivio tar con pristine-tar. Si può fare il rebase delle patch con gbp-pq e si può usare git stesso per risolvere qualsiasi conflitto che si è creato.

Fare il merge di un ramo debian-experimental in master per sid

Poniamo che si abbiano i seguenti rami:

upstream

più recente versione a monte in fase di sviluppo

upstream-1.5

serie 1.5 a monte, considerata stabile

master

ramo per creare pacchetti per sid

debian-experimental

ramo per creare pacchetti per experimental

  • Si importa ogni rilascio in upstream-1.5 e si fa il merge in master
  • Si fa il merge di ogni rilascio beta (1.6~beta) in upstream e si fa il merge in debian-experimental

Ad un certo punto si vuole spostare il lavoro da debian-experimental al ramo master e rilasciarlo in unstable.

Come prima cosa è necessario assicurarsi che debian-experimental abbia tutto a posto in debian/*: forse si è fatto il commit di qualcosa in master e non lo si è scelto anche per debian-experimental. Si possono confrontare le sottogerarchie debian/ con:

git checkout master
git diff debian-experimental debian

Se necessario, riportare una a una le modifiche in debian-experimental. Il prossimo merge azzererà tutto in master e lo sostituirà con il contenuto del ramo debian-experimental. L'unica cosa che viene mantenuta è debian/changelog dato che deve riflettere la cronologia delle modifiche all'interno di sid e non deve contenere dettagli sui singoli rilasci in experimental. Ecco come farlo (assicurarsi che master sia uno spazio di lavoro pulito):

git checkout master
git clean -fd && git checkout .
git merge -s ours debian-experimental
git diff --binary debian-experimental | git apply -R --index
git reset debian/changelog
git checkout debian/changelog
git commit -m 'Merge 1.6.0~rc1 from debian-experimental' --amend

Dopo aver fatto questo, è caldamente raccomandato ispezionare il merge con gitk e con git diff prima di fare il push su alioth o qualsiasi altro sviluppatore. Ad esempio

git diff debian-experimental

invocato in master dovrebbe mostrare solo il changelog, dato che ogni altra cosa in master dovrebbe essere ora identica a debian-experimental.

Conclusione

Queste sono tutte le informazioni di base da sapere per ciò che riguarda la creazione di pacchetti con Git! È raccomandato, per iniziare, di fare copie dei pacchetti e provare gli strumenti su repository temporanei; una volta che si pensa di aver preso dimestichezza con questo, ci sono altre opzioni che andrebbero viste.

Ulteriori opzioni

pbuilder

Per usare pbuilder, si deve semplicemente cambiare in ~/.gbp.conf o /etc/git-buildpackage/gbp.conf builder in /usr/bin/git-pbuilder.

{i} /usr/bin/git-pbuilder può essere modificato per usare opzioni aggiuntive, come --builddir e --debsign-k.

Firmare le etichette

Quando si usano gli strumenti git-import-dsc o git-import-orig, possono essere usate le seguenti opzioni:

--sign-tags

se firmare le etichette

--keyid=gpg-keyid

con quale chiave gpg firmare le etichette

pristine-tar

git-buildpackage permette anche di usare pristine-tar, un nuovo strumento sviluppato da Joey Hess per ricreare archivi tar identici a partire da un piccolo file delta e i file nella directory attuale.

Se si abilita pristine-tar, quando si esegue git-import-dsc o git-import-orig viene fatto il commit dei file delta in un ramo pristine-tar. quando si crea il pacchetto usando gbp buildpackage, l'archivio tar esatto viene rigenerato usando pristine-tar.

L'opzione --pristine-tar può essere usata sia quando si usa lo strumento git-import-dsc sia git-import-orig. Quando si esegue gbp buildpackage, si può usare l'opzione --git-pristine-tar. Si può anche abilitare l'opzione pristine-tar in /etc/git-buildpackage/gbp.conf.

Eseguire lintian dopo la compilazione

Aggiungere quanto segue a ~/.gbp.conf :

postbuild = lintian -I $GBP_CHANGES_FILE && echo "Lintian OK"

Eseguire autopkgtest dopo la compilazione

Come prima cosa configurare un ambiente per adt (vedere la documentazione di autopkgtest, man adt-run) Poi aggiungere quanto segue al proprio ~/.gbp.conf :

postbuild = adt-run --changes $GBP_CHANGES_FILE --- schroot sid-amd64-sbuild; [ $? -eq 0 -o $? -eq 8 ]

L'ultimo controllo serve a evitare fallimenti nel caso in cui non ci sono controlli da eseguire.

Esempio di gbp.conf

[DEFAULT]
builder = git-pbuilder
cleaner = fakeroot debian/rules clean
# Creare pristine-tar all'importazione
pristine-tar = True
# Eseguire lintian per controllare il pacchetto dopo la compilazione
postbuild = lintian -iIE --pedantic $GBP_CHANGES_FILE && echo "Lintian OK"""

[buildpackage]
export-dir = ../build-area/

[import-orig]
# Filtrare via file/dir non desiderati dal codice originale a monte
filter = [
    '*egg.info',
    '.bzr',
    '.hg',
    '.hgtags',
    '.svn',
    'CVS',
    '*/debian/*',
    'debian/*'
    ]
# filtrare i file dagli archivi tar passati a pristine-tar
filter-pristine-tar = True

[import-dsc]
filter = [
    'CVS',
    '.cvsignore',
    '.hg',
    '.hgignore',
    '.bzr',
    '.bzrignore',
    '.gitignore'
    ]

[dch]
# ignorare i messaggi di merge commit
git-log = --no-merges

Vedere anche

  • Salsa - server di sviluppo collaborativo per Debian basato sul software GitLab

  • /usr/share/doc/git-buildpackage
  • cowbuilder e git-pbuilder possono essere utili

Collegamenti esterni