Debian contemplates patch management
Autor original: Jonathan Corbet
Publicado originalmente no: https://lwn.net/
Tradução: Roberto Bechtlufft
Os desenvolvedores do projeto Debian tiveram uma semana de muito trabalho limpando a casa depois que a vulnerabilidade do openssl foi anunciada. Depois que o problema foi resolvido, o Debian parou para repensar seus procedimentos. Obviamente, alguns furos na maneira como o Debian lida com os patches de seus programas vieram à tona, e agora o projeto gostaria de encarar o problema e melhorar as coisas no futuro. A discussão que se originou daí mostra um Debian mais introspectivo, e pode surtir efeitos aos quais as outras distribuições devem ficar atentas. Como disse um desenvolvedor do Fedora: “esse bug poderia ter nos atingido facilmente.” Todos os distribuidores fazem alterações em seus pacotes, e todos estão potencialmente expostos a esse tipo de falha.
A política de empacotamento do Debian lembra a de muitas outras distribuições. Um pacote fonte do Debian supostamente inclui um tarball (um arquivo .tar compactado) contendo o código fonte original, sem alterações, do upstream (que é a entidade de origem do programa, como o projeto openssl, por exemplo). Quaisquer patches específicos da distribuição são incluídos separadamente e aplicados quando o pacote fonte é preparado para a compilação. Mas há algumas questões específicas do Debian a serem resolvidas:
- Pelo que se tem ouvido da discussão, parece que a regra do “tarball cristalino do upstream” volta e meia é quebrada pelos desenvolvedores. Às vezes não há opção: algumas distribuições de código do upstream contêm material que, devido a questões de licença, não pode ser empacotado pelo Debian. A justificativa para os outros casos já não é tão clara.
- Os patches do Debian são todos postos juntos em um único arquivo diff. Por isso, não há metadados descrevendo os patches, e é difícil separá-los uns dos outros. Nesse sentido, o Debian difere de outras distribuições baseadas no RPM, que costumam manter os patches separados.
O resultado é que é complicado para os outros revisar os patches do Debian, é complicado para o projeto upstream avaliar as mudanças e é mais complicado ainda para os desenvolvedores do Debian lidar com tudo isso.
Raphaël Hertzog deu início a um debate sobre como melhorar essa situação. Uma parte importante da abordagem dele (uma idéia que também é apoiada por outros) é fazer alterações ao formato de pacotes do Debian para tornar mais explícita a natureza de cada patch. Os empacotadores deveriam, no mínimo, incluir um diretório debian/patches junto com os fontes, e esse diretório conteria cada patch, em arquivos separados. Alguns pacotes do Debian já são montados assim, mas a prática está longe de ser universal.
Além disso, seria ótimo se o pacote fonte “entendesse” o patch e seus metadados. Já há propostas para que isso se realize: Raphaël apóia o formato “3.0 (quilt),” que mantém os patches (em um tarball separado) como uma série do quilt. O formato parece ter bastante apoio; dentre outras coisas, sua simplicidade facilitaria a criação de pacotes nesse formato pelos desenvolvedores do Debian, sem que eles precisassem aprender a usar novas ferramentas. O arquivo de série do quilt – como o arquivo spec usado em pacotes RPM – deixa claro quais patches devem ser aplicados, e em qual ordem.
Mas há outras variantes do formato de pacotes fontes 3.0. O formato “3.0 (git)” contém um repositório git com o código fonte do upstream e uma série de patches. Essa abordagem tem a vantagem de incluir um histórico de patches com os metadados. Ela também poderia, quem sabe, fazer com que outros distribuidores (incluindo o upstream) selecionassem com mais facilidade os patches interessantes. Por outro lado, um formato de pacotes baseado no git exige a disponibilidade do git e tem grandes chances de aumentar o tamanho dos pacotes. O FAQ do GitSrc tem mais informações sobre o formato; também há outra variante do formato, o “3.0 (bzr)”.
Qualquer dos novos formatos, se adotado em larga escala, traria um novo nível de transparência às atividades com patches do Debian. Isso permitiria a criação de um site “patches.debian.org” (claramente inspirado no patches.ubuntu.com), onde qualquer um poderia dar uma rápida olhada nas alterações realizadas em um pacote específico. Alguns desenvolvedores acham que não há muita utilidade nisso. Eles temem que os desenvolvedores do upstream não se interessem em usar um site para verificar as alterações feitas ao código. No entanto, ao menos um desenvolvedor (o hacker do GNOME, Vincent Untz) acredita que o site patches.debian.org seria um passo na direção certa.
Também há gente dizendo que o Debian não precisa de uma nova infra-estrutura de gerenciamento de patches. Alguns dizem que o local adequado para se acompanhar patches é no projeto upstream. Ninguém parece duvidar que mais patches devem voltar ao upstream, mas é preciso considerar que muitos patches jamais voltarão para lá. Os desenvolvedores upstream de vários projetos têm objetivos diferentes e são vistos pelos mantenedores das distribuições como avessos à cooperação. E alguns patches – como os que removem material não livre – podem não ser desejados nem pelos mantenedores cooperativos. Por isso sempre haverá a necessidade de patches específicos para cada distribuição. A abordagem “acompanhe pelo upstream” não vai resolver o problema.
Enquanto isso, Joey Hess trouxe uma idéia completamente diferente à mesa: tratar qualquer divergência do upstream como um bug. Cada patch teria uma entrada correspondente no BTS (sistema de rastreamento de bugs) do Debian, com uma tag especial. Qualquer um poderia listar esses bugs, exibir os patches e participar na discussão associada a eles. O uso do BTS oferece algumas vantagens técnicas reais, uma vez que o sistema já existe. Mas, como disse Joel, o maior benefício é outro.
A maior razão para se usar o BTS não é técnica. É que, se decidirmos que o projeto deve tratar divergências do upstream como bugs, é porque decidimos efetivamente que os mantenedores são responsáveis por minimizar divergências desnecessárias, comunicá-las ao upstream e acompanhar as divergências existentes. Afinal, os desenvolvedores são responsáveis por seus bugs.
Um mecanismo de rastreamento de patches, pelo contrário, seria em grande parte um subsistema automático em um lado que não exerceria o mesmo tipo de pressão sobre os desenvolvedores.
Mas a abordagem do BTS também não é uma unanimidade. Alguns desenvolvedores afirmam que a maioria dos patches específicos do Debian não são bugs do Debian, mas sim bugs do upstream. Quer isso seja verdade ou não, rastreadores de bugs de distribuições geralmente trazem várias entradas que, no fim das contas, descrevem bugs nos pacotes upstream. Outra reclamação é que a criação e a manutenção de entradas no BTS seria mais um trabalho burocrático imposto aos desenvolvedores do Debian. Sem dúvida, alguns desenvolvedores vão encarar desta forma.
Mas pode ser que nesse ponto mais burocracia faça sentido. Os distribuidores de Linux de todo o mundo (e não apenas os do Debian) aplicam milhares de patches nos programas livres que distribuem. Tornar mais explícita a natureza e o impacto desses patches só pode favorecer a usuários, revisores, distribuidores e mantenedores do upstream. Uma clara conclusão à qual se chega com os eventos recentes é a de que todos os distribuidores podem se esforçar mais para informar à comunidade sobre as alterações que promovem.
A habilidade de um programador de aplicar patches a um programa é parte crucial do ecossistema – é a maneira do distribuidor balancear as necessidades dos usuários com as políticas dos mantenedores do upstream. Mas os distribuidores precisam ser mais claros quanto às mudanças que estão fazendo, estar dispostos a devolver essas mudanças ao upstream sempre que possível, e cobrar o feedback do upstream sobre os patches. Qualquer “burocracia” que ajude a realizar isso vai ajudar à comunidade de um modo geral, de maneiras que extrapolam a simples prevenção de outro desastre com o do openssl.
Uma última observação: a existência de formatos de pacotes fontes que incorporam repositórios de sistemas de controle de versão distribuído mostram que os desenvolvedores já pensam no problema há algum tempo. Isso não é meramente uma resposta aos eventos recentes. Há um projeto discutindo os reais benefícios que a interseção entre um controle de versão e o empacotamento pode trazer aos distribuidores. O projeto pode ser encontrado em vcs-pkg.org. Eles estão trabalhando na organização de um evento em setembro em Extremadura. Vale à pena acompanhar o vcs-pkg. Ele tem potencial para melhorar as coisas para usuários e desenvolvedores de todas as distribuições.
Créditos a Jonathan Corbet – https://lwn.net/
Tradução por Roberto Bechtlufft <robertobech at gmail.com>
