8.11.06

Binários no Linux - Instalação de Programas

Enquanto buscava na net algo sobre dependência de pacotes achei esse texto que, não expressa por completo a minha opinião, mas traz algo proveitoso em termos de consientização. Não sejamos arrogantes ao ponto de não percebemos que temos que melhorar. O Linux é o "unico" SO que roda na minha maquina há quase 5 anos e não tenho nenhuma pretensão de usar um outro e de modo algum esse texto mudou minha opinião quanto a isso.

Nota: O texto segue exatamente como foi traduzido pelo autor, não expresso minha opinião em nenhum momento.

Segue o texto:

Você já ficou maravilhado com outros sistemas operacionais tais como Windows, MacOS ou mesmo BeOS, nos quais a tarefa de instalar softwares é bem mais simples do que em Linux? Nestes sistemas operacionais você pode simplesmente baixar um arquivo .ZIP/.RAR/.EXE/etc, descompactar em uma pasta e rodar diretamente do conteúdo, ou então um instalador gráfico irá te auxiliar por todo o processo de instalação.

Estas facilidades não são encontradas em Linux, no qual há dois modos básicos para instalação de softwares: compilando ou instalando pacotes. Métodos os quais são usualmente complicados e inconsistentes entre si, sem mencionar a dificuldade para os novos usuários. Mesmo nos casos em que o gerenciamento de pacotes é simplificado, como no caso das distribuições mais populares do Linux, os desenvolvedores não conseguem ainda prover pacotes para todas as distribuições, ou mesmo para todas as versões de compiladores.

Neste espaço vou procurar traduzir fielmente o texto onde o autor expõe o porquê da dificuldade dos desenvolvedores proverem aplicativos de maneira mais simples.

Resumidamente, por que não conseguimos instalar e distribuir programas da mesma maneira simples como é feita em outros sistemas operacionais para desktops? A resposta reside no "layout" e funcionalidades do sistema de arquivos do Linux, mantidos assim pelas distribuições Linux por motivo de compatibilidade. Este "layout" é e sempre foi dirigido a ambientes multi-usuários, onde resguardar e distribuir recursos ao longo do sistema (ou mesmo através de uma LAN) era o fator chave para redução do enorme custo armazenamento e utilização de memória. Mas com a tecnologia atual e com a chegada do computador pessoal, muito desta filosofia de gerenciamento de recursos não parece mais fazer sentido.

A seguir o autor relaciona quatro fatores que, em seu ponto de vista, tornam a distribuição de binários e suas respectivas bibliotecas complicadas no Linux.

1. Distribuição por local físico.
2. "Instalações Globais" ou "Inferno das Dependências versus Inferno das Dlls".
3. Diretório corrente não consta no PATH.
4. Ausência de arquivo metadata.

1 - Distribuição por local físico.

Muitas vezes notamos diretórios que contêm os seguintes subdiretórios:

lib/ - contendo bibliotecas compartilhadas.
bin/ - contendo binários/scripts executáveis.
sbin/ - contendo binários somente acessíveis ao "super usuário".

Se você procurar ao longo do sistema de arquivos, você encontrá muitos locais onde estes nomes de diretórios se repetem, por exemplo:

/
/usr
/usr/local
/usr/X11R6

Então você pode se perguntar o porquê de os arquivos serem distribuídos desta maneira. Isto está ligado à razões históricas, como "/" sendo um disco de inicialização ou rom, "/usr" sendo um ponto de montagem global, originalmente carregado a partir de fita magnética, disco compartilhado ou mesmo pela rede, "/usr/local" para instalação local de softwares, quanto ao "/usr/X11R6" o autor não tem idéia, quem sabe pelo seu tamanho muito grande.

Pode ser notado que até recentemente, sistemas baseados em Unix foram desenvolvidos visando tarefas específicas, e nunca para abrigarem uma grande variedade de programas como é no caso dos computadores pessoais. É por isto que não notamos diretórios organizados por finalidade, diferentemente de outros sistemas Unix-Like (principalmente BeOS e OSX), ao invés disto temos estes diretórios organizados por local físico.

Muitos anos atrás, empresas como SGI e SUN decidiram atacar este problema criando o diretório "/opt". Este diretório pensado para conter os programas e seus dados compartilhados (tais como bibliotecas e binários) os quais eram exportados para o "root filesystem" (em /usr) através da criação de links simbólicos. Isto tornava simples a tarefa de desinstalar programas, bastando deletar o diretório do aplicativo e então rodar um script para remoção dos links inválidos. Esta abordagem nunca foi popular entre as distribuições Linux, e mesmo assim esta abordagem não resolve o problema dos pacotes de bibliotecas.

2 - "Instalações Globais" ou "Inferno das Dependências versus Inferno da Dlls".

Devido aos fatos apresentados anteriormente, todos os métodos usuais de instalação de softwares (tanto pacotes binários, assim como fontes) forçam o usuário a instalar globalmente no sistema, disponibilizando para todas as contas. Com esta abordagem, todos os binários vão para locais comuns (/usr/bin, /usr/lib, etc). Apesar de ter suas vantagens, como o uso maximizado das bibliotecas compartilhadas, o método apresenta limitações. Isto faz com que todos os programas se utilizem de um mesmo conjunto de bibliotecas com versões compatíveis entre todos eles, o que não permite a instalação de mais de uma versão de um mesmo programa.

Por causa disto também, se torna impossível aos desenvolvedores embutir apenas as bibliotecas necessárias para uma revisão de um binário específico (muito arriscado), então o usuário é forçado a instalar as bibliotecas necessários por si mesmo. Isto nos leva a lidar com o "inferno das dependências", que acontece quando o usuário baixa um programa (fonte, pacote, ou binário compartilhado) e este informa que mais bibliotecas (antigas ou novas) são necessárias para rodar o programa.

Apesar da implementação de bibliotecas compartilhadas no Linux ser mais complexa do que aquelas presentes no Windows, é o sistema de arquivos que não permite a distribuição de binários com as respectivas bibliotecas embutidas, as quais o usuário provavelmente não tem.

Um truque sujo é embutir as bibliotecas dentro do executável, isto é chamado "static linking", mas esta abordagem têm muitos obstáculos, tal como o aumento do uso de memória por instância de programa, "error tracing" mais complexo, e mesmo limitações de licenciamento em muitos casos, sendo assim, este método não é encorajado normalmente.

Para concluir com este ítem, temos que dizer que é difícil para os desenvolvedores distribuírem binários com versões específicas de bibliotecas embutidas. Lembrando que nem todas as bibliotecas precisam ser embutidas, mas somente aquelas que se espera que o usuário não tenha no sistema. Bibliotecas mais utilizadas como "libc", "libz" ou mesmo GTK ou QT podem permanecer disponíveis globalmente no sistema.

Muitos poderiam apontar que esta abordagem lida com o que conhecemos como "Inferno das Dlls", muito conhecido em sistemas Windows. Mas isto atualmente ocorre porque programas que portam bibliotecas fundamentais disponibilizadas globalmente no Windows, sobrescrevem versões atuais com versões mais antigas. Isto em parte acontece porque o Windows não suporta múltiplas versões de uma biblioteca como no Unix, mas também porque, no momento do boot o kernel pode apenas carregar bibliotecas no formato de arquivo 8.3 (você pode ter bibliotecas em formatos de arquivo diferentes deste). Como maneira de se resguardar, desde o Windows 2000 é mantido um diretório com cópias das versões mais recentes das bibliotecas disponíveis no caso de algum programas sobrescrevê-las. Em resumo, "Inferno das Dlls" pode ser definido como a falta de alguma versão específica de biblioteca do sistema.

3 - Diretório corrente não consta no PATH.

Isto é um tanto simples, mas tem que ser também colocado. Por padrão, em sistemas "Unix-Like" o "current path" não é reconhecido como um "path" para biblitecas ou binários. Por causa disto, você pode descompactar um arquivo e rodar o binário nele contido. Muitos binários compartilhados que são disponibilizados usam o expediente de criar um "shellscript" contendo algo como o que segue:

#!/bin/sh

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
./mybinary

Isto pode ser Resolvido de maneira simples adicionando-se "." ao "path" da biblioteca e binário, mas nenhuma distro o faz, porque não é padrão nos sistemas "Unix-Like". Claro que, do ponto-de-vista da aplicação é perfeitamente normal acessar dados a partir de caminhos relativos, então você ainda tem subdiretórios com dados.

4 - Ausência de arquivo metadata.

Sempre nos maravilhamos com o fato de os binários para Windows possuírem seus próprios ícones e nos perguntamos o porquê de não ser da mesma maneira no Linux? Isto ocorre porque não há um modo padrão de definir metadata nos arquivos. Isto significa que não é possível embutir um pequeno pixmap dentro do arquivo. Devido a isto, é difícil explicitar qual binário, ou mesmo arquivo, o usuário deve rodar. Não é possível afirmar que isto seja uma limitação do ELF (Executable and Linking Format), desde que este permitirá adicionar suas próprias seções ao binário, mas há uma certa falta de padronização de como fazer isto.



original: http://www.osnews.com/story.php?news_id=2377
autor: Juan Linietsky

Link para referência