Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• it/PackagingWithGit

Wiki/

---

Pacchettizzazione con Git

Questa pagina descrive come usare gli strumenti "gbp" ("git-buildpackage") per impostare e mantenere pacchetti sorgenti Debian in un repository git. Dopo aver impostato un repository git di questo tipo (chiamato repository di pacchettizzazione git), nelle parti seguenti di questa pagina viene discusso anche come creare pacchetti binari Debian direttamente da repository di pacchettizzazione git esistenti.

Nomenclatura dei rami Git

Esiste uno schema standard per i nomi dei rami ("branch") usati per la pacchettizzazione. È descritto in DEP-14: Recommended layout for Git packaging repositories. Questa pagina segue tale standard, ma ci sono ancora molti pacchetti che non lo fanno. Il vecchio schema più comune prevede di usare master invece di debian/latest per il ramo principale della pacchettizzazione, e upstream invece di upstream/latest per il ramo con il codice a monte più recente.

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

Iniziare

Importare i sorgenti originali a monte come archivio tar

È più facile creare la prima versione di un pacchetto fuori da Git, è anche possibile fare un pacchetto non completo e rilasciato e crearlo come solo sorgente; 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.

Prima di tutto, se non è ancora stato fatto, debian/gbp.conf dovrebbe avere debian-branch e upstream-branch per usare i nomi DEP14, e inoltre abilitare pristine-tar se si desidera usarlo aggiungendo --pristine-tar nel comando sottostante.

$ gbp import-dsc /path/to/package_0.1-1.dsc --debian-branch=debian/unstable --upstream-branch=upstream/latest

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 (alias gbp) ha fatto quanto segue:

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

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

• importata la directory debian/ nel ramo debian/latest 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 debian/latest dal rilascio upstream/latest e aggiungere la directory debian/ come commit.

Successivo lavoro di pacchettizzazione

Ora si può lavorare nel ramo debian/latest 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.

Se l'archivio tar originale a monte è già nella forma nome-pacchetto_versione.orig.tar.gz (Es. package_0.2.orig.tar.gz), allora 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/latest. È necessario usare git merge per fare il merge di questo ramo in debian/latest 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 debian/latest per sid

Poniamo che si abbiano i seguenti rami:

• Si importa ogni rilascio in upstream-1.5 e si fa il merge in debian/latest

• Si fa il merge di ogni rilascio beta (1.6~beta) in upstream/latest e si fa il merge in debian/experimental

Ad un certo punto si vuole spostare il lavoro da debian/experimental al ramo debian/latest 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 debian/latest e non lo si è scelto anche per debian/experimental. Si possono confrontare le sottogerarchie debian/ con:

git checkout debian/latest
git diff debian/experimental debian

Se necessario, riportare una a una le modifiche in debian/experimental. Il prossimo merge azzererà tutto in debian/latest 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 debian/latest sia uno spazio di lavoro pulito):

git checkout debian/latest
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 salsa o qualsiasi altro sviluppatore. Ad esempio

git diff debian/experimental

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

Conclusione

Queste sono tutte le informazioni di base da sapere per ciò che riguarda la manutenzione di pacchetti sorgente e la creazione di pacchetti binari 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 per la compilazione di pacchetti binari, si deve semplicemente cambiare in ~/.gbp.conf o /etc/git-buildpackage/gbp.conf 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=openpgp-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

• Pagina web di Git

• Wiki di Git

• Manuale di Git

• Il progetto vcs-pkg

• 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

• Manuale di Git-buildpackage

• Guida a Git del Team Perl di Debian

---

• CategoryDeveloper CategoryPackaging CategoryGit