NOME¶

dgit-nmu-simple - tutorial para DDs que querem fazer NMU com o git

INTRODUÇÃO E ESCOPO¶

This tutorial describes how a Debian Developer can do a straightforward NMU of a package in Debian, working (only) in git.

Este documento não vai ajuda-lo a decidir se um NMU é uma boa ideia ou se vai ser bem recebido. O Referência a Desenvolvedores Debian tem algumas orientações sobre isto (por vezes questionáveis).

Por outro lado, você não precisa de saber nada sobre o normal fluxo de trabalho git dos maintainers. Se for apropriado, você pode trabalhar em muitos pacotes diferentes, fazendo alterações semelhantes, sem se preocupar com as práticas git individuais dos maintainers.

Este tutorial apenas cobre alterações que podem ser expressadas sensivelmente como um pequeno número razoável de cometeres lineares (seja para empacotamento Debian ou para ficheiros do autor ou ambos).

Se você deseja fazer uma nova versão de autor, vai provavelmente querer fazer como o maintainer teria feito. Você precisa de descobrir quais são as práticas git do maintainer e consultar o tutorial de fluxo de trabalho "dgit-maint-*(7)" apropriado.

SUMÁRIO¶

    % dgit clone glibc bookworm
    % cd glibc
    % git am ~/glibc-security-fix.diff
    % dch --nmu "Apply upstream's fix for foo bug."
    % git add debian/changelog && git commit -m"NMU changelog entry"
    % dpkg-buildpackage -uc -b
    [ correr os seus testes ]
    % dch -r && git add debian/changelog && git commit -m"Finalise NMU"
    % dgit -wgf sbuild -A -d trixie
    [ quaisquer testes finais nos .debs gerados ]
    % dgit -wgf [--delayed=5] push-source bookworm
    [ insira a sua frase-passe gnupg quando pedida ]
    [ veja se o empurrar e o envio tiveram sucesso ]
    [ prepare e envie email do diff do NMU (git-diff, git-format-patch) ]

QUE TIPO DE ALTERAÇÕES E COMETERES A FAZER¶

Quando preparar um NMU, o cometer de git que fizer no ramo dgit deve ser uma série de cometeres lineares simples com boas mensagens do cometido. As mensagens do cometido irão ser publicadas de várias maneiras, incluindo talvez serem usadas como mensagens de capa para as patches quilt geradas.

Não faça cometeres de fusão. Não tente re-basear para deitar fora patches existentes - se precisar de reverter uma alteração que é realmente uma patch Debian, use git-revert.

Se você precisar modificar uma patch Debian, faça um novo cometer que corrija o que precisa ser corrigido, e explique na mensagem do cometido qual patch deve ser esborrachada (talvez usando uma mensagem do cometido no formato "git rebase --autosquash -i").

(É claro que se você tiver instruções específicas do maintainer, você pode seguir essas em vez destas. Mas o procedimento deste tutorial é legítimo para qualquer maintainer, no sentido que deve gerar um envio para o qual o maintainer não pode razoavelmente objetar.)

PREPARANDO E REVISANDO O RAMO LOCAL¶

O ramo dgit/sid é um ramo git local normal que segue um ramo do autor (sintético). Assim você pode livremente rescrever quaisquer cometidos que fez localmente e não os empurrou para lado nenhum, como é normal.

Uma coisa que é esquisita é os cometeres "quilt fixup" (que aparecem se você fizer ex dgit sbuild). Se você estiver a re-basear-los de todo, você pode e deve apenas larga-los; o dgit irá depois regenera-los conforme necessário.

Tudo isto baseia-se num facto subjacente:

O dgit não tem estado git invisível em nenhum lado. Assim se você re-basear para fora o quilt fixup, e re-trabalhar o seu ramo, o seu ramo vai continuar bem porque parece-se tal como ficava se você apenas fizesse esses cometeres diretamente. (NB git-debrebase tem um estado fora-de-ramo esquisito.)

RAMOS RELEVANTES¶

O dgit clone irá coloca-lo num ramo como "dgit/sid". Existe um pseudo-remoto chamado "dgit" que também contém um ramo como "dgit/sid", então você faz coisas como "git diff dgit/dgit/sid" para ver as alterações que você fez.

MANTER A SUA ÁRVORE DE TRABALHO ORGANIZADA¶

Não esqueça de fazer "git add" a quaisquer novos ficheiros que crie. Caso contrário o git clean (que é requisitado com a opção "-wgf" na receita em cima) irá apaga-los.

Muitas compilações de pacote deixam as árvores git sujas. Assim, cometer antes de compilar. Desse modo você pode usar "git reset --hard".

Se você seguir esta abordagem não precisa de se preocupar com o sujar da compilação na árvore. Também significa que não se preocupa com o alvo de limpeza do pacote, o que também está bem porque muitos alvos de limpeza de pacote estão estragados.

OUTROS RAMOS GIT¶

O histórico git do dgit (visível com gitk e o log do git) não está necessariamente relacionado com o histórico git do maintainer ou do autor (se existir).

Se o maintainer publicitou um repositório git com Vcs-Git, o dgit irá configurar um remoto para ele, assim você pode fazer

    % git fetch vcs-git

Você pode escolher alterações a partir de lá, por exemplo. Note que o histórico git do maintainer pode não ser apropriado para usar com o dgit. Por exemplo, pode existir um ramo de patches-não-aplicadas ou até conter apenas um directório debian/.

ENVIAR PARA ATRASADO¶

Você pode usar a opção --delayed do dgit para enviar para a fila de espera ATRASADA. No entanto, você deve ler o aviso sobre esta opção em dgit(1).

VEJA TAMBÉM¶

dgit(1), dgit(7), dgit-maint-*(7)