Contents
- Empacotando com Git
Empacotando com Git
Esta página descreve como usar as ferramentas gbp (git-buildpackage) para configurar e manter pacotes-fonte Debian em um repositório git. Depois de configurar esse repositório git (conhecido como repositório de empacotamento git - git packaging repository), mais adiante neste artigo também discute-se como construir pacotes binários Debian diretamente a partir de repositórios de empacotamento git já existentes.
Note-se que este é apenas um guia introdutório muito geral. A documentação oficial completa pode ser encontrada no pacote git-buildpackage (consulte a documentação online).
Para obter ajuda na conversão de repositórios Subversion criados por svn-buildpackage para git, consulte a subpágina de conversão svn-buildpackage.
Você também deve ler sobre o suporte a pristine-tar abaixo.
Esta página descreve o fluxo de trabalho usando os comandos do pacote git-buildpackage. Alternativamente, há também git-dpm e gitpkg.
Nomes de branches Git
Existe um esquema de nomenclatura padronizado para os branches usados nos empacotamentos. O esquema está descrito em DEP-14: layout recomendado para repositórios de empacotamento Git. Esta página segue esse padrão, mas ainda há muitos pacotes que não o seguem. O padrão antigo mais comum é usar master em vez de debian/latest para o ramo de empacotamento principal, e upstream em vez de upstream/latest para o branch com o código upstream mais recente.
Métodos de importação do upstream
Existem duas maneiras principais de importar o código upstream para o repositório debianizado:
Pode-se importar tarballs de lançamento upstream em um repositório específico do Debian. Isso cria um commit por lançamento. Isso geralmente é feito com o comando gbp import-orig. Este é o método mais geral porque assume apenas que o(a) upstream está liberando tarballs.
Se o(a) upstream estiver usando o git para gerenciar sua fonte, o repositório de debianização pode ficar em um ramo da árvore principal do(a) upstream. Claro que isso pode funcionar apenas com alguns(mas) upstreams, mas a grande vantagem é que a relação entre a debianização e o código upstream é muito nítida. Criação de patches e lançamentos são muito mais naturais. Como os repositórios Debian APT ainda usam tarballs, você ainda tem que gerenciá-los nessa configuração, mas pristine-tar existe para esse fim.
Há também uma terceira opção, que é uma combinação das duas: gbp import-orig --upstream-vcs-tag. Isso é útil principalmente quando o orig tarball não é idêntico à tag de lançamento upstream, o que pode acontecer se, por exemplo,
- o tarball foi reempacotado (para remover peças não DFSG, por exemplo)
o script que o(a) upstream usa para fazer tarballs faz alterações (make dist do autotools faz isso em alguns projetos)
As várias vantagens e desvantagens são discutidas aqui:
Começando
Importando do(a) upstream como tarballs
É mais fácil primeiro criar a primeira versão de um pacote fora do Git. Uma vez feito, você deve importar o pacote usando o comando import-dsc da ferramenta gbp. Anteriormente, o comando era git-import-dsc. O diretório em que é chamado será o diretório pai do novo repositório Git.
$ gbp import-dsc /caminho/para/pacote_0.1-1.dsc
Isso exibirá os resultados de seu progresso e fará alguns commits. A seguir, você terá alguns novos arquivos e diretórios:
$ ls pacote/ pacote_0.1-1.orig.tar.gz
Olhando no novo repositório, nota-se que git-buildpackage (vulgo gbp) fez o seguinte:
Importou os arquivos do pacote (mas não o diretório debian/) para o branch upstream/latest
Criou a tag upstream/0.1, onde 0.1 é o número da versão do seu pacote
Importou o diretório debian/ para o ramo debian/latest, bem como os arquivos do(a) upstream
Etiquetou o último commit como debian/0.1-1, já que assume que o pacote está concluído.
Usando o repositório do(a) upstream
Se o(a) upstream já estiver usando git, basta criar um branch para a debianização. As convenções para nomes de ramos e tags seguem os casos que acabamos de descrever, de modo que se pode ramificar debian/latest a partir do lançamento upstream/latest, e adicionar o diretório debian/ como um commit.
Fluxo de trabalho de empacotamento posterior
Agora você pode trabalhar no ramo debian/latest para editar o pacote. Faça um commit com:
$ git commit -a
e construa o pacote com:
$ gbp buildpackage
Depois de ter produzido um pacote pronto para lançamento, você deve etiquetá-lo, da seguinte maneira:
$ gbp buildpackage --git-tag
Certifique-se de que o seu arquivo debian/changelog está correto, pois é ele que será usado para criar a tag. A etiqueta será chamada debian/0.1-2, onde 0.1-2 é a versão Debian.
Lidando com patches debian
A ferramenta gbp-pq pode ser usada para rastrear patches no git e exportá-los/importá-los de/para a série quilt em debian/patches.
Atualizando para uma nova versão upstream
Importando do(a) upstream com tarballs
Quando uma nova versão upstream for lançada, use o comando import-orig para adicioná-lo ao repositório. Anteriormente, esse comando era git-import-orig.
Usando um arquivo debian/watch (recomendado)
$ gbp import-orig --uscan
Usando um arquivo tarball
$ gbp import-orig /caminho/para/novo-upstream.tar.gz -u 0.2
onde 0.2 é o novo número de versão upstream.
Se o tarball upstream já estiver na forma nomepacote_versão.orig.tar.gz (por exemplo, pacote_0.2.orig.tar.gz), então a opção -u não é necessária.
Usando o repositório upstream
Se estivermos usando o repositório upstream, podemos fazer git fetch na nova tag de lançamento no repositório, para o branch upstream/latest. Precisamos unir com git merge este ramo em debian/latest, e fazer um commit do novo tarball com pristine-tar. Pode ser feito um rebase do patches com gbp-pq, e o próprio git pode ser usado para resolver quaisquer conflitos que tenham sido criados.
Combinando um branch debian/experimental em debian/latest para sid
Vamos assumir que você tenha os seguintes ramos::
upstream/latest |
último upstream em desenvolvimento |
upstream-1.5 |
série upstream 1.5, considerada estável |
debian/latest |
branch para construir pacotes para sid |
debian/experimental |
branch para construir pacotes para experimental |
Você está importando cada lançamento pontual em upstream-1.5 e combinando em debian/latest
Você está combinando cada versão beta (1.6~beta) em upstream/latest e fundindo em debian/experimental
Em algum momento, você deseja mover o trabalho de debian/experimental para o ramo debian/latest, e liberá-lo para a instável (unstable).
Primeiro, é necessário certificar-se de que debian/experimental tem tudo correto em debian/* - talvez você tenha feito o commit de algo em debian/latest e não selecionou (cherry-pick) para debian/experimental. Você pode comparar as subárvores debian/ dessa forma:
git checkout debian/latest git diff debian/experimental debian
Se necessário, selecione (cherry-pick) qualquer alteração em debian/experimental. A próxima mesclagem irá obliterar tudo em debian/latest e substituirá pelo conteúdo do ramo debian/experimental. A única coisa que é mantida é debian/changelog, porque precisa refletir o histórico de mudanças dentro do sid e não precisa conter detalhes de lançamentos individuais para a experimental. Veja como fazemos isso (certifique-se de que debian/latest é um espaço de trabalho limpo):
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
Depois de fazer isso, é fortemente sugerido que você inspecione o merge com gitk e com git diff antes de fazer push para salsa ou para qualquer outro(a) desenvolvedor(a). Por exemplo,
git diff debian/experimental
chamado em debian/latest deve somente exibir o changelog, porque tudo mais em debian/latest deve agora ser idêntico a debian/experimental.
Conclusão
Isso é tudo sobre o básico para manter pacotes-fonte e construir pacotes binários com o Git! Eu recomendaria fazer cópias de pacotes e experimentar as ferramentas em repositórios temporários, para começar. Uma vez que você sinta que as dominou, existem outras opções que devem ser analisadas.
Mais opções
pbuilder
Para usar o pbuilder para construções de pacotes binários, simplesmente altere builder em ~/.gbp.conf ou /etc/git-buildpackage/gbp.conf para /usr/bin/git-pbuilder
/usr/bin/git-pbuilder pode ser editado para usar opções adicionais, tais como --builddir e --debsign-k...
Assinando etiquetas
Ao chamar ambas as ferramentas git-import-dsc ou git-import-orig, as seguintes opções podem ser usadas:
--sign-tags
- Para assinar tags
--keyid=openpgp-keyid
- Com qual chave OpenPGP assinar as tags
pristine-tar
git-buildpackage também suporta o uso de pristine-tar, uma nova ferramenta desenvolvida por Joey Hess para recriar tarballs idênticos de um pequeno arquivo delta e os arquivos no diretório atual.
Se você ativar pristine-tar, é feito um commit de arquivos delta para o ramo pristine-tar se você chamar git-import-dsc ou git-import-orig. Quando você constrói o pacote usando gbp buildpackage, o tarball exato é regenerado usando pristine-tar.
Ao chamar qualquer uma das ferramentas git-import-dsc ou git-import-orig, a opção --pristine-tar pode ser usada. Ao chamar gbp buildpackage, a opção --git-pristine-tar pode ser usada. Você também pode ativar a opção --pristine-tar em /etc/git-buildpackage/gbp.conf.
executando lintian após a construção
Adicione isto a ~/.gbp.conf :
postbuild = lintian -I $GBP_CHANGES_FILE && echo "Lintian OK"
executando autopkgtest após a construção
Primeiro configure um ambiente para adt (veja a documentação do autopkgtest, man adt-run). Em seguida, adicione isso ao seu ~/.gbp.conf:
postbuild = adt-run --changes $GBP_CHANGES_FILE --- schroot sid-amd64-sbuild; [ $? -eq 0 -o $? -eq 8 ]
A última verificação está lá para evitar falhas quando não há testes para executar.
Um arquivo gbp.conf de exemplo
[DEFAULT]
builder = git-pbuilder
cleaner = fakeroot debian/rules clean
# Cria pristine-tar na importação
pristine-tar = True
# Executa lintian para verificar um pacote após a construção
postbuild = lintian -iIE --pedantic $GBP_CHANGES_FILE && echo "Lintian OK"""
[buildpackage]
export-dir = ../build-area/
[import-orig]
# Filtra arquivos/diretórios não desejados do(a) upstream
filter = [
'*egg.info',
'.bzr',
'.hg',
'.hgtags',
'.svn',
'CVS',
'*/debian/*',
'debian/*'
]
# Filtra arquivos do tarball passados para pristine-tar
filter-pristine-tar = True
[import-dsc]
filter = [
'CVS',
'.cvsignore',
'.hg',
'.hgignore',
'.bzr',
'.bzrignore',
'.gitignore'
]
[dch]
# Ignora mensagens merge nos commits
git-log = --no-merges
Veja também
Salsa - servidor de desenvolvimento colaborativo para Debian baseado no software GitLab
/usr/share/doc/git-buildpackage
cowbuilder e git-pbuilder também podem ser úteis
Links externos
Página principal do Git
Wiki do Git
Manual do Git
Usando Git para empacotamento Debian por Russ Allbery
Discussão sobre como incluir o git upstream no git do pacote
Co-manutenção de um pacote Debian com git, git-buildpackage e pbuilder por Philipp Huebner