Size: 5516
Comment: sync with English master
|
Size: 7894
Comment: sync with English master
|
Deletions are marked like this. | Additions are marked like this. |
Line 54: | Line 54: |
Quando è disponibile una nuova versione a monte, usare lo strumento {{{git-import-orig}}} per aggiungerla al repository, in questo modo: | Quando è disponibile una nuova versione a monte, usare lo strumento {{{git-import-orig}}} per aggiungerla al repository. === Usando un file debian/watch (raccomandato) === {{{ $ git-import-orig --uscan }}} === Usando un file di archivio tar === |
Line 62: | Line 70: |
== 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 94: | Line 143: |
* [[cowbuilder]] può essere utile | * [[cowbuilder]] e [[git-pbuilder]] possono essere utili |
Line 103: | Line 152: |
* [[http://people.debian.org/~debalance/packaging-with-git.html|Co-mantenere un pacchetto Debian con git, git-buildpackage e pbuilder]] di Philipp Huebner |
Translation(s): English - Italiano
Contents
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.
Iniziare
È 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
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
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:
$ git-buildpackage
Una volta prodotto un pacchetto pronto per il rilascio, lo si dovrebbe etichettare nel modo seguente:
$ git-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.
Aggiornamento ad una nuova versione originale a monte
Quando è disponibile una nuova versione a monte, usare lo strumento git-import-orig per aggiungerla al repository.
Usando un file debian/watch (raccomandato)
$ git-import-orig --uscan
Usando un file di archivio tar
$ git-import-orig /percorso/della/nuova-a-monte.tar.gz -u 0.2
dove 0.2 è il nuovo numero di versione originale a monte.
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.
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.
/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 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. Si può anche abilitare l'opzione pristine-tar in /etc/git-buildpackage/gbp.conf.
Vedere anche
?Usare Git su Alioth
- /usr/share/doc/git-buildpackage
cowbuilder e git-pbuilder possono essere utili
Collegamenti esterni
Usare Git per la pacchettizzazione di Debian di Russ Allbery
discussione su come includere il git upstream nel git del pacchetto
Co-mantenere un pacchetto Debian con git, git-buildpackage e pbuilder di Philipp Huebner