Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• pt_BR/debian/patches

debian/patches

Esta página resultou da seguinte discussão na lista debian-devel em janeiro de 2008: <alpine.DEB.1.00.0801250818360.5187@wr-linux02>. Também inclui ideias da discussão #250202 sobre a Política Debian.

Nota: O formato de patch agora é uma DEP, DEP-3: Diretrizes de etiquetamento de patches.

Sistemas existentes

Características gerais

Pacotes usando o sistema dpatch podem ser convertidos facilmente para o sistema quilt, o qual tem melhor suporte por outros softwares; por exemplo, guilt para git.

Alvos patching/unpatching que podem ser incluídos em debian/rules

Graças à cooperação dos(as) mantenedores(as) do dpatch, quilt e CDBS, os alvos patch e unpatch tornaram-se os padrões.

Observe que, no caso do quilt, pode ser melhor usar $(QUILT_STAMPFN), já que patch é um alvo phony.

Limitações

Usuários(as) de um pacote-fonte precisam da fonte desempacotada não pronta para construção, mas pronta para inspeção e modificação. Os dois principais casos de uso são a aplicação de modificações locais (menores) (correções de segurança, opções de tempo de compilação), e inspeção manual ou automatizada do código-fonte (auditoria, pesquisa). Isso deve ser possível sem instalar pacotes adicionais além do dpkg-dev.

Foi discutido que o uso de sistemas de patch estava dificultando o trabalho das equipes de portes, NMUs, segurança e qualidade por várias razões:

1. Profusão de sistemas de patch. As pessoas teriam que aprendê-los todos e ser capazes de detectar qual o sistema usado no pacote em que estão trabalhando.

2. A dificuldade de reempacotar as fontes. Se as modificações diretas dos pacotes-fonte bloquearem o alvo unpatch, e se esse alvo for chamado clean, o dpkg-buildpackage falhará.

3. Esta abordagem não é compatível com o formato 3.0 (quilt).

4. Documentos como /usr/share/doc/debian/source-unpack.txt não alertam que as modificações nas fontes recém-desempacotadas podem quebrar a etapa de patch.

Proposed improvements

• Basta documentar como corrigir as fontes em um arquivo chamado README.source, cujo modelo poderia ser fornecido no pacote do sistema de patches usado.

• Padronize a interface dos sistemas de patch.

• Use um único envoltório (wrapper), possivelmente obrigatório. Bugs: 4588 e outros.

• "Qualifique" os sistemas que são difundidos e duráveis, e desencoraje o uso de outros.

• Faça dpkg-source aplicar os patches automagicamente após desempacotar as fontes (usando procedimentos internos).

• Alternativamente, faça com que o dpkg-source envie uma mensagem informativa se detectar que um sistema de patch é usado.

• Envie as fontes com patch (o alvo clean chamaria patch). Revés: incha o diff.gz.

• Implemente um alvo chamado patched, que fornece fontes em tal estado que chamar debian/rules binary não reverterá as mudanças introduzidas.

Ideias rejeitadas

• Fazer dpkg-source chamar a receita de patching:

  • Esta é uma ameaça à segurança;
  • Exigiria que as dependências de construção de um pacote fossem instaladas.

  • Em vez disso, dpkg-source faz o próprio patching no formato 3.0 (quilt) que foi implementado nesse meio tempo.

Usando um VCS (em vez de um sistema de patch) para rastrear alterações

Manter um pacote inteiro, incluindo fontes upstream, em um sistema de controle de versão (VCS) é frequentemente usado como um método de gerenciamento da modificação para fontes upstream.

Comparação entre dois paradigmas

É claro que o uso do VCS tem outras vantagens, mas essa tabela se concentra na perspectiva de sua substituição para sistemas de gerenciamento de patches.

• Eu monitoro minhas mudanças de empacotamento em um VCS e não sou obrigado(a) a manter a fonte upstream no VCS. O que impede que usuários(as) de um VCS mantenham apenas debian/ no repositório VCS e, por exemplo, bzr-buildpackage --merge para se fundir com a fonte upstream separada? - BenFinney 2008-10-06

Questões não respondidas

• Grupos de commits podem ser mais confusos do que um patch bem documentado: enquanto um patch pode ser modificado, um commit só pode ser revertido por outro commit, adicionando ainda mais complexidade ao grupo de commits. Como as informações contidas na quebra de lógica das modificações para upstream em um conjunto de patches podem ser transmitidas no paradigma VCS?

Situação atual

No momento da versão dpkg 1.14.17, o formato 3.0 foi incluído e os bugs: 4588 e outros foram fechados.

FixMe: renomear página para DebianPatches? O endereço "debian/*" não parece se adequar à hierarquia wiki.

CategoryPackaging