Pela experiência pessoal com o Debian (2009-2023), pela comparação com distros de outros “ramos” da “árvore de distros Linux”, pelas conversas nos Fóruns etc., acabei formando uma vaga ideia sobre o Debian – mas nunca tinha encontrado nada tão esclarecedor, e tão bem resumido, quanto essa postagem de Lars Wirzenius em seu blog (que também não conhecia):
Por que o Debian é do jeito que é?
08/10/2023 12:14
- O que o Debian quer ser
- A constituição, estrutura de poder, governança
- Contrato social e diretrizes de software livre Debian
- Autônomo
- Nenhuma biblioteca agrupada
- Processo de adesão
- Liberar nomes de códigos
- Mudando lentamente
O Debian é um sistema operacional grande e complexo e um enorme projeto de código aberto. Já tem trinta anos. Para muitas pessoas, alguns de seus aspectos são estranhos. A maioria dessas coisas tem um bom motivo, mas pode ser difícil descobrir qual é. Esta é uma tentativa de responder a algumas dessas questões, sem ser um histórico detalhado do projeto.
O que o Debian quer ser
O Debian quer ser um sistema operacional de uso geral seguro e de alta qualidade que consiste apenas em software livre e de código aberto que roda na maioria dos tipos de computadores em uso ativo no mundo.
Por propósito geral quero dizer que o Debian deve ser adequado para a maioria das pessoas e para a maioria dos propósitos. Sempre haverá situações em que isso não será adequado, por qualquer motivo, mas é um bom objetivo a ser alcançado. Algumas outras distribuições visam propósitos específicos: um desktop, um servidor, jogos, pesquisas científicas, etc. Não há problema em ter como objetivo um propósito geral ou específico, mas a escolha do objetivo leva a diferentes decisões ao longo do caminho.
Para o Debian, ter como objetivo ser de uso geral significa que o Debian não escolhe o que empacotar com base no propósito do software. A única escolha real que o Debian faz aqui é se o software é gratuito e se é plausível para o Debian manter um pacote de alta qualidade.
A constituição, estrutura de poder, governança
O Debian é uma das organizações de código aberto mais explicitamente democráticas. Possui processos bem definidos para tomada de decisões e elege anualmente um líder de projeto. Além disso, os poderes do líder do projecto são estritamente limitados e a maioria dos poderes normalmente associados à liderança são explicitamente delegados a outras pessoas.
O pano de fundo histórico para isso é que os primeiros líderes do projeto Debian eram implicitamente ditadores todo-poderosos até decidirem renunciar. Depois, um líder de projecto foi longe demais e uma revolta expulsou-os e a democracia foi introduzida. Como parte disso, o projeto obteve uma constituição formal , que define as regras do projeto.
A razão pela qual o Debian tem as regras que tem é porque menos regras e menos burocracia não funcionaram para o Debian no início de sua história.
Contrato social e diretrizes de software livre Debian
Em meados da década de 1990, antes da introdução do termo código aberto, o que era “software livre” foi definido pela Free Software Foundation, mas de uma forma que deixou muito a ser interpretado. O Debian queria ter regras mais claras, e criou as Diretrizes de Software Livre Debian, e as tornou parte de seu Contrato Social.
O contrato social é a promessa do Debian para si mesmo e para o mundo em geral sobre o que o Debian é e faz. O DFSG faz parte disso. Este é um documento fundamental para o Debian, e alterá-lo é intencionalmente dificultado na constituição do Debian.
As regras mais detalhadas deixaram mais claro o que o Debian aceitará e simplificaram as discussões sobre isso. Ainda há muito o que discutir, é claro.
O DFSG foi mais tarde a base da Definição de Código Aberto.
Autônomo
O Debian insiste em ser independente. Qualquer coisa que seja empacotada no Debian, pelo Debian, deve ser construída (compilada) usando apenas dependências do Debian. Além disso, tudo no Debian deve ser construído pelo Debian. Isso pode causar muito trabalho extra. Por exemplo, as ferramentas de linguagem de programação atuais muitas vezes assumem que podem baixar dependências de repositórios online em tempo de construção, e isso não é aceitável para o Debian.
A principal razão para isso é que uma dependência pode não estar disponível posteriormente. O Debian não tem controle sobre repositórios de pacotes de terceiros, e se um pacote, ou repositório inteiro, desaparecer, pode ser impossível para o Debian reconstruir o pacote. O Debian precisa ser reconstruído para atualizar para um novo compilador, para corrigir um problema de segurança, para portar para uma nova arquitetura ou apenas para fazer alguma alteração no software empacotado, incluindo correções de bugs.
Se o Debian não fosse independente, estaria à mercê de qualquer uma das dezenas de milhares de pacotes que possui, e de todas as suas dependências, estando disponíveis quando uma correção de segurança urgente precisasse ser lançada. Isto não é aceitável para o Debian e, portanto, o Debian escolhe fazer o trabalho de empacotar todas as dependências.
Isso significa, é claro, que para o Debian empacotar algo pode dar muito trabalho.
Nenhuma biblioteca agrupada
O Debian evita usar cópias de bibliotecas ou outras dependências que acompanham o software que ele empacota. Muitos projetos upstream acham mais fácil agrupar ou “fornecer” dependências, mas para o Debian, isso significa que pode haver muitas cópias de algumas bibliotecas populares. Quando houver necessidade de consertar um problema de segurança ou outro problema grave em tal biblioteca, o Debian terá que encontrar todas as cópias para corrigi-las. Isso pode dar muito trabalho e, se o problema de segurança for urgente, será uma perda de tempo valioso fazer isso.
Por exemplo: o zlib é usado por um grande número de projetos. Pela sua natureza, necessita processar dados que podem ser construídos para explorar uma vulnerabilidade na biblioteca. Isso aconteceu. A certa altura, o Debian encontrou dezenas de cópias empacotadas do zlib em seu arquivo e despendeu um esforço considerável para garantir que apenas a versão empacotada do zlib fosse usada pelos pacotes no Debian.
Assim, o Debian opta por fazer o trabalho antecipadamente, antes que seja urgente, enquanto empacota o software, e garante que o pacote no Debian use a versão da biblioteca empacotada no Debian.
Isso nem sempre é apreciado pelos desenvolvedores upstream, que preferem ter que lidar apenas com a versão da biblioteca que agrupam. Essa é a versão com a qual eles verificaram seu próprio software. Isso às vezes leva a atritos com o Debian.
Processo de adesão
Dado o tamanho e a complexidade do Debian como sistema operacional, e sua popularidade, o projeto precisa confiar em seus membros. Isto significa especialmente confiar naqueles que carregam novos pacotes. Devido às limitações técnicas do Linux na década de 1990, todo pacote Debian tem acesso root completo durante sua instalação. Em outras palavras, todo desenvolvedor Debian pode potencialmente se tornar o usuário root em qualquer máquina rodando Debian. Com dezenas de milhões de máquinas rodando Debian, isso representa potencialmente muito poder.
O Debian avalia seus novos membros de várias maneiras. Idealmente, cada novo membro faz parte da comunidade de desenvolvimento Debian há tempo suficiente para ser conhecido por outros e construiu confiança dentro da comunidade.
O processo pode ser bastante frustrante para aqueles que desejam ingressar no Debian, especialmente para alguém acostumado com um projeto menor de código aberto.
Liberar nomes de códigos
O Debian atribui um nome de código para cada versão principal. Isto foi feito originalmente para tornar o espelhamento do arquivo de pacotes Debian menos dispendioso.
Em meados da década de 1990, quando o Debian estava perto de lançar seu lançamento 1.0, os codinomes não eram usados. Em vez disso, o arquivo tinha um diretório para cada lançamento, nomeado de acordo com sua versão. O desenvolvimento de uma nova versão demora um pouco, então o diretório “1.0” foi criado com bastante antecedência. Infelizmente, um editor de CD-ROMs produziu prematuramente um disco rotulado como 1.0, antes que o Debian tivesse realmente terminado de fazer 1.0. Isto significava que as pessoas que obtiveram o CD-ROM do Debian 1.0 obtiveram algo que não era realmente 1.0.
Uma solução óbvia para evitar que isso acontecesse novamente seria preparar o lançamento em um diretório chamado “1.0-not-released” e renomear o diretório para “1.0” após o término do lançamento. No entanto, isso significaria que todos os espelhos teriam que baixar novamente a versão quando o nome do diretório mudasse. Isso teria custado caro, dado o enorme tamanho do Debian (centenas de pacotes! dezenas de megabytes!). Assim, o Debian optou por usar nomes de código.
Mais tarde, a estrutura “pool” foi adicionada ao arquivo Debian. Com isso, os arquivos de todas as versões ficam na mesma árvore de diretórios e os arquivos de metadados especificam quais arquivos pertencem a cada versão. Isso torna o espelhamento mais fácil. Pode ser possível abandonar os codinomes e manter as versões agora, mas não sei se o Debian estaria interessado nisso.
Mudando lentamente
Como implícito acima, o Debian é enorme. É enorme. É enorme. Na verdade, não é mais tão pequeno.
Grandes navios param lentamente. Grandes projetos mudam lentamente. Qualquer mudança no Debian que afete grande parte de seus pacotes pode exigir o trabalho de centenas de voluntários. Isso não vai acontecer rapidamente.
Às vezes o trabalho pode ser feito com apenas um pequeno número de pessoas, e o Debian possui processos para permitir isso. Por exemplo, se uma nova versão do compilador GNU C for carregada, o trabalho de descobrir quais correções em outros pacotes precisam ser feitas geralmente pode ser feito por um punhado de pessoas.
Muitas vezes, uma mudança leva tempo porque é necessário construir consenso, e isso requer uma discussão extensa, que leva tempo e só raramente pode ser interrompida.
Tudo isso também significa que os desenvolvedores Debian tendem a ser conservadores nas decisões técnicas. Freqüentemente, preferem soluções que não exijam mudanças em grande escala.