Aplicativos e bibliotecas no mesmo pacote?

Quando se fala em instalação de pacotes, é tradição no Linux separar bibliotecas e binários de aplicativos em pacotes diferentes, de modo que apenas uma versão de uma biblioteca seja instalada e compartilhada entre os aplicativos que fazem uso dela. Outros sistemas operacionais, como o Windows e o MacOS X, costumam incluir uma versão da biblioteca em questão no mesmo pacote do aplicativo, o que pode resultar em diversas cópias e versões de uma mesma biblioteca coexistindo no sistema. Cada abordagem tem seus defensores: a do Linux é vista por muitos como superior porque uma correção de segurança em uma biblioteca muito popular não exige a atualização de vários aplicativos diferentes, sem falar na economia de espaço. Mas parece que a Mozilla e o Google podem estar fazendo com que distribuições mudem para a abordagem das bibliotecas empacotadas junto com os binários para que a manutenção da compatibilidade com seus navegadores, o Firefox e o Chromium.

Um dos problemas encontrados pelas distribuições ao empacotar o Chromium, a versão de software livre do navegador Google Chrome, é que ele inclui código de versões alternativas de várias bibliotecas. Como sintetizou o gerente de engenharia do Fedora, Tom “spot” Callaway, “o Google está criando forks de partes de código livre e aberto para uso no Chomium no mesmo pique em que um coelho produz filhotes: com frequência, e sem pensar muito bem no que está fazendo”. Para distribuições como o Fedora, que tem a política “Sem Bibliotecas Embutidas“, fica muito difícil incluir o Chromium. Mas o problema não se restringe a esse navegador.

A Mozilla está começando a adotar um modelo de lançamentos diferente, que pode exigir mudanças da parte das distribuições. A ideia é incluir novos recursos nas versões menores (que geralmente são lançadas para corrigir falhas de segurança), que sairiam com periodicidade de quatro a seis semanas. As versões principais sairiam em intervalos de seis meses, e versões principais antigas não teriam mais suporte depois que uma versão subsequente fosse lançada. Embora o plano seja controverso, especialmente no que diz respeito a agrupar segurança e recursos nas versões menores, pode ser que ele funcione para a Mozilla, e para os usuários que a Mozilla tem no Windows.

Só que as distribuições Linux costumam oferecer suporte por bem mais do que seis meses ou um ano. Enquanto a Mozilla der suporte a uma versão específica vai ser fácil continuar fazendo isso, mas depois vai ficar mais complicado. As distribuições geralmente fazem backports de correções de segurança de versões mais recentes do Firefox para as versões mais antigas incluídas em seus lançamentos, mas se a Mozilla diminuir o tempo de suporte isso não vai ser tão fácil. A criação de backports também pode ser ilegal de acordo com as diretrizes de marca comercial da Mozilla; foram essas diretrizes que fizeram com que o Debian criasse o “Iceweasel“. A alternativa, que seria atualizar o Firefox para sua versão mais recente, tem lá os seus problemas.

É provável que uma nova versão do Mozilla use bibliotecas atualizadas, diferentes das usadas por outros pacotes da distribuição. Dependendo das mudanças realizadas nessas bibliotecas, pode ser bem simples usá-las nesses aplicativos, mas é preciso fazer testes. Ter várias bibliotecas modificadas também pode ter efeitos colaterais. E ainda há o problema do xulrunner.

O objetivo do xulrunner é isolar aplicativos que queiram embutir componentes Mozilla (como o renderizador Gecko) das alterações realizadas na plataforma Mozilla. Mas o xulrunner não tem uma API muito estável, e atualizações no xulrunner podem levar a uma enxurrada de atualizações. Vários pacotes (Miro, Epiphany, Liferea, Yelp e outros) usam o xulrunner, e as alterações realizadas nele podem exigir atualizações nessas dependências, que por sua vez podem exigir outras bibliotecas atualizadas e por aí vai.

A solução adotada pelo Windows e pelo Mac tem a vantagem de que as atualizações no Firefox não exigem coordenação com os outros aplicativos, mas também tem sua própria dose de problemas. Cada aplicativo precisa de uma maneira de alertar seus usuários sobre correções de segurança importantes, e ter algum mecanismo para que seus usuários atualizem o aplicativo. Em vez de contar com um repositório central encarregado de todas as questões de segurança pendentes, os usuários têm que rodar seus aplicativos um por um para atualizar o sistema. Além disso, uma falha em uma biblioteca que seja amplamente usada pode exigir a atualização de dezenas de centenas de aplicativos, enquanto no modelo do Linux basta atualizar uma única biblioteca.

Parece que o Ubuntu está se preparando para migrar para a abordagem de bibliotecas empacotadas junto com o Firefox na próxima versão da distro, a 10.04 (Lucid Lynx). Essa versão do Ubuntu vai ser LTS, ou seja, vai ter suporte por três anos no desktop. Você já deve estar imaginando como vai ser difícil oferecer suporte ao Firefox 3.6 até 2013, e analisando as coisas sob essa perspectiva a mudança faz sentido. Mas a mudança tem outras implicações.

Para começar, o link acima menciona a necessidade de “eliminar aplicativos com componentes Mozilla embutidos”, porque eles podem dificultar a atualização do Firefox: “aplicativos que façam uso do gecko de formas não triviais devem ser eliminados de versões estáveis do Ubuntu; para isso, devemos migrá-los para uma variante existente do webkit. Se não houver um port do webkit, será preciso portá-los para a árvore da próxima versão do xulrunner”. Continuando a leitura, dá para notar que encontrar alternativas no Webkit para aplicativos que usam o Gecko é a prioridade, com a remoção do Ubuntu (presumimos que para o repositório “universe”) sendo o provável resultado da maioria dos pacotes que usam o xulrunner.

O Ubuntu também pretende usar as bibliotecas embutidas no Firefox, e não as usadas pelo resto do sistema, ao menos em parte devido a problemas na experiência de usuário: “o uso de bibliotecas do sistema não conta com suporte oficial dos desenvolvedores do Firefox; essa abordagem já gerou uma grande quantidade de trabalho no passado, e por vezes resultou em uma experiência não ideal para nossos usuários. Isso ocorreu devido a diferenças entre as versões de bibliotecas presentes no Ubuntu lançado e as versões otimizadas dessas bibliotecas embutidas nos pacotes compactados distribuídos pelo Firefox”. Embora essa decisão esteja mais afinada com o desejo da Mozilla, ela certamente viola um princípio básico das distribuições Linux. Não que pareça perigoso fazer isso com um pacote, mas corre-se o risco da distribuição “abrir a porteira”.

O modelo de lançamentos do Chromium é ainda mais sufocante, já que cada versão lançada tem como objetivo substituir a anterior. Como descreveu Callaway, o Chromium contém várias versões modificadas de bibliotecas, o que torna difícil para as distribuições fazer um pacote oficial sem as bibliotecas embutidas. Se essa situação do Chromium se concretizar no Ubuntu, por exemplo, já teríamos dobrado a quantidade de aplicativos com bibliotecas embutidas. Pode parecer pouco pular de um para dois, mas e se outros projetos de software começarem a trilhar o mesmo caminho?

A política do Fedora à qual nos referimos acima vale uma leitura e traz alguns bons motivos para que não sejam incluídas bibliotecas embutidas, mas há algumas possibilidades interessantes para um sistema que aceite essas bibliotecas. Seria bem mais fácil usar aplicativos em um ambiente restrito de “sandbox”, com todo o código em um lugar só, em um compartimento ou “jaula” isolada. O suporte a várias versões diferentes de um mesmo aplicativo também ficaria mais fácil.

Essa abordagem é fundamentalmente diferente da forma como as distribuições Linux sempre operaram de modo geral, mas parte disso é uma questão histórica. Embora a banda de dados não seja gratuita, ela vem caindo de preço rapidamente. Espaço em disco hoje em dia é barato, e o preço também está caindo. Talvez haja espaço para uma abordagem diferente. Uma distribuição ainda poderia servir como um repositório central de pacotes, e o que talvez seja mais importante, como um órgão regulador para recomendações de segurança desses pacotes.

Levar a coisa além e isolar esses aplicativos no sistema, de modo que eventuais danos causados por alguma falha sejam limitados, também pode ser uma experiência muito interessante. O mundo do software livre é um excelente candidato para esse tipo de experiência; na verdade, é difícil de imaginar isso sendo feito de outra maneira. Os sistemas operacionais proprietários não têm uma “mão livre” para reempacotar os aplicativos que rodam neles. Parece provável que os pontos negativos acabem superando os positivos, mas só vamos saber tentando.