| Capítulo 11. Empacotar com git | ||
|---|---|---|
 |
 |
|
| Capítulo 11. Empacotar com git | ||
|---|---|---|
| |
|
|
Índice
Até ao “Capítulo 10, Empacotamento avançado”, nós concentrava-nos em operações de empacotamento sem usar Git ou qualquer outro VCS. Estas operações de empacotamento tradicionais eram baseadas no tarball lançado pelo autor como mencionado em “Secção 10.1, “Perspetiva histórica””.
Atualmente, o comando git(1) é a plataforma de-facto par a ferramenta VCS e é a parte essencial para ambos desenvolvimento do autor e atividades de empacotamento Debian. (Veja Debian wiki “Empacotamento git Debian formatos de ramo de maintainer e fluxos de trabalho” para fluxos de trabalho VCS existentes.)
![[Nota]](images/note.png) | Nota |
|---|---|
|
Como o pacote fonte Debian não-nativo usa “diff -u” como sua tecnologia backend para a modificação do maintainer, não pode representar modificações que envolvam links simbólicos, permissões de ficheiros, nem dados binários (Março 2022 discussão em debian-devel@l.d.o). Por favor evite fazer tais modificações de maintainer mesmo sabendo que estas podem ser gravadas no repositório Git. |
Como os fluxos de trabalho VCS são um tópico complicado e existem muitos estilos práticos, aqui vou apenas tocar nalguns pontos chave com informação mínima.
Salsa é o serviço de repositório Git remoto com as ferramentas associadas. Oferece a plataforma de colaboração para atividades de empacotamento Debian usando uma instância de aplicação GitLab. Veja:
Existem 2 estilos nomes de ramo para o repositório Git usado para o empacotamento. Veja “Secção 11.4, “Nomes de ramos:””.
Existem 2 estilos de utilização principais para o repositório Git para o empacotamento. Veja:
Existem 2 ferramentas notáveis de empacotamento Debian para o repositório Git para o empacotamento.
gbp(1) e os seus sub-comandos:
dgit(1) e os seus sub-comandos:
É altamente desejável hospedar o pacote de código fonte Debian em Salsa. Mais de 90% de todos os pacotes de código fonte Debian estão hospedados Salsa. [21]
O repositório VCS exacto que hospeda um pacote de código fonte Debian pode
ser identificado por um campo de metadados Vcs-* que pode
ser visualizado com o comando apt-cache showsrc
<nome-pacote>.
Após assinar uma conta no Salsa, certifique-se que as seguintes páginas têm o mesmo endereço de e-mail e as chaves GPG que você configurou para usar com Debian, assim como a sua chave SSH:
Salsa corre o serviço Salsa CI como uma instância de GitLab CI para “Secção 10.4, “Integração contínua””.
Para cada instância de “git push”, testa quais testes de mímica podem correr no pacote Debian oficial ao definir o ficheiro de configuração do Salsa CI “Secção 6.13, “Ficheiro debian/salsa-ci.yml”” como:
--- include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml # Customizations here
O repositório Git para o empacotamento Debian deve ter pelo menos 2 ramos:
Neste tutorial, são usados nomes de ramo no estilo antigo nos exemplos para simplicidade.
| Nota |
|---|---|
|
Este upstream-branch pode precisar de ser criado usando tarball lançado pelo autor independente repositório Git do autor pois tende a conter ficheiros gerados automaticamente. |
O conteúdo do repositório Git do autor pode co-existir no repositório Git local para o empacotamento Debian ao adicionar uma cópia dele. Ex.:
[debhello] $ git remote add upstreamvcs <url-upstream-git-repo> [debhello] $ git fetch upstreamvcs master:upstream-master
Isto permite selecção fácil a partir do repositório Git do autor para correção de bugs.
O repositório Git de patch não-aplicada pode ser resumido a:
A árvore fonte corresponde ao conteúdo extraído por “dpkg-source -x --skip-patches” do pacote fonte Debian.
This repository style is useful for all variants of traditional workflows and gbp based workflow:
“Secção 5.10, “Patch por abordagem “diff -u”””
Use scripts de ajuda como o dquilt(1) e gbp-pq(1) para gerir dados nos ficheiros debian/patches/*.
Use dput(1) para enviar o pacote fonte Debian.
Os ficheiros debian/source/local-options e debian/source/local-patch-header destinam-se a ser guardados pelo comando git. Estes não são incluídos no pacote fonte Debian.
| Nota |
|---|---|
|
The focus of this introductory tutorial “Guide for Debian Maintainers” isn’t the patch applied Git repository which is rather a new trend. So minimal explanation is given here. |
O repositório Git de patch aplicada pode ser resumido a:
A árvore fonte corresponde aos conteúdos extraídos pelo “dpkg-source -x” do pacote fonte Debian.
Use um dos estilos de fluxo de trabalho:
Fluxo de trabalho do dgit-maint-merge(7).
Fluxo de trabalho do dgit-maint-debrebase(7).
O comando gbp é fornecido pelo pacote git-buildpackage.
Use “gbp import-orig” para importar o novo tar de autor para o repositório git.
Use “gbp buildpackage” para compilar o pacote binário Debian a partir do repositório git.
A gestão de histórico do pacote com o pacote git-buildpackage está a tornar-se na prática standard para muitos maintainers Debian. Veja mais em:
O comando dgit é fornecido pelo pacote dgit.
Este comando é desenhado para gerir os conteúdos de “Secção 11.6, “Repositório Git de patch aplicada”” de modo eficiente.
O novo pacote dgit oferece comandos que interagem com o repositório Debian como se fosse um repositório git. Não substitui o gbp-buildpackage e ambos podem ser usados ao mesmo tempo. Usar gbp-buildpackage simples é recomendado para desenvolvedores que querem correr push/pull de git em Salsa e usam coisas como Salsa CI ou Merge Requests em Salsa.
Para mais detalhes veja os guias extensivos:
O comando dgit(1) pode empurrar o histórico de alterações fácil-de-seguir para o sítio https://browse.dgit.debian.org/ e pode enviar um pacote Debian para o repositório Debian apropriadamente sem usar o dput(1).
Here are some hints.
Topics around dgit are beyond this tutorial document to cover them in depth. Please start reading relevant information:
dgit(1)
Para “Secção 11.5, “Repositório Git de patch não-aplicada””, você pode gerar ficheiros debian/patches/* usando o comando gbp-pq(1) a partir de commits git feitos para o ramo patch-queue.
Ao contrário do dquilt que oferece funcionalidade semelhante como visto “Secção 5.11, “Patch por abordagem dquilt”” e “Secção 9.5, “Gerir a lista de patch com dquilt””, o gbp-pq não usa ficheiros .pc/* para seguir o estado da patch, mas em vez disso o gbp-pq utiliza ramos temporários no git.
Você pode adicionar, retirar, e refrescar ficheiros debian/patches/* com o gbp-pq para gerir a lista das patch.
Se o pacote for gerido em “Secção 11.5, “Repositório Git de patch não-aplicada”” usando o pacote git-buildpackage, você pode revisar a fonte do autor para corrigir bug como maintainer e lançar uma nova revisão Debian usando gbp pq.
Adiciona uma nova patch que grava a modificação à fonte do autor no ficheiro buggy_file como:
[debhello] $ git checkout master [debhello] $ gbp pq import gbp:info: ... imported on 'patch-queue/master [debhello] $ vim buggy_file ... [debhello] $ git add buggy_file [debhello] $ git commit [debhello] $ gbp pq export gbp:info: On 'patch-queue/master', switching to 'master' gbp:info: Generating patches from git (master..patch-queue/master) [debhello] $ git add debian/patches/* [debhello] $ dch -i [debhello] $ git commit -a -m "Closes: #<bug_number>" [debhello] $ git tag debian/<version>-<rev>
Drop (== desactiva) um caminho existente
Refresca ficheiros debian/patches/* para fazer o “dpkg-source -b” funcionar como esperado após atualizar um pacote Debian para o novo lançamento do autor.
[debhello] $ git checkout master [debhello] $ gbp pq --force import # ensure patch-queue/master branch gbp:info: ... imported on 'patch-queue/master [debhello] $ git checkout master [debhello] $ gbp import-orig --pristine-tar --uscan ... gbp:info: Successfully imported version ?.?.? of ../packagename_?.?.?.orig.tar.xz [debhello] $ gbp pq rebase ... resolve conflicts and commit to patch-queue/master branch [debhello] $ gbp pq export gbp:info: On 'patch-queue/master', switching to 'master' gbp:info: Generating patches from git (master..patch-queue/master) [debhello] $ git add debian/patches [debhello] $ git commit -m "Update patches" [debhello] $ dch -v <newversion>-1 [debhello] $ git commit -a -m "release <newversion>-1" [debhello] $ git tag debian/<newversion>-1
Para pacotes fonte Debian chamados “<pacote-fonte>” guardados no arquivo snapshot.debian.org, pode ser gerado um repositório git inicial gerido em “Secção 11.5, “Repositório Git de patch não-aplicada”” com todo o histórico de versão Debian como se segue.
[debhello] $ gbp import-dscs --debsnap --pristine-tar <source-package>
O esquema de empacotamento quase-nativo empacota uma fonte sem o real tarball de autor usando o formato de pacote não-nativo.
![[Dica]](images/tip.png) | Dica |
|---|---|
|
Algumas pessoas promovem este esquema de empacotamento quase-nativo mesmo para programas escritos apenas para Debian pois ajuda a facilitar a comunicação com as distribuições baseadas como a Ubuntu para correções de bugs e etc. |
Este esquema de empacotamento quase-nativo envolve 2 passos de preparação:
Organiza a sua árvore fonte quase como o pacote Debian nativo (veja “Secção 6.4, “Pacote Debian nativo””) com ficheiros debian/* com algumas excepções:
Gera o tarball de autor em falta de preferência sem ficheiros debian/*.
O resto é o mesmo como o fluxo de trabalho de empacotamento não-nativo como escrito em “Secção 6.1, “Fluxo de trabalho de empacotamento””.
Apesar de isto poder ser feito de muitas maneiras (“Secção 16.3, “Snapshot upstream tarball””), você pode usar o repositório Git e “git deborig” como:
[~] $ cd /path/to/debhello [debhello] $ dch -r ... set its <version>-<revision>, e.g., 1.0-1 [debhello] $ git tag -s debian/1.0-1 [debhello] $ git rm -rf debian [debhello] $ git tag -s upstream/1.0 [debhello] $ git commit -m upstream/1.0 [debhello] $ git reset --hard HEAD^ [debhello] $ git deborig [debhello] $ sbuild
When your local Git commit history becomes intertwined, you need to organize it before pushing it out to the public.
The most simple organization process is to squash all changes to a single commit using “git rebase -i”. But this may create a huge illegible commit. Manually splitting the squashed commit using the splitdiff command from the patchutils is an option but may be quite cumbersome.
More fine grained organization process can use “git rebase -i” in combination with “git add some_file” and “git commit”. But this may be quite cumbersome.
For this task, the “git ime” command in the imediff package can help. It automatically splits a single commit with many files into multiple commits involving only a single file changes. When operating on a single file change commit, it interactively splits the commit into multiple commits of line changes. Invoking it with the --auto* option will automate this commit operation. Now you can manage changes interactively using “git rebase -i”. By using gitk on the working tree along this task, you get decent visibility over all commits.
| |
|
|
| Capítulo 10. Empacotamento avançado |
|
Capítulo 12. Dicas |