O fato do PC-BSD ter uma instalacão fácil, intuitiva e agradável é sim um fato importante para sua popularizacão. Ser um sistema estável, de alta performance e seguro claramente não é suficiente para sua popularizacão em ambiente Desktop. Já, ser de fácil uso e ter um resultado rasoável por padrão após a instalacão, também é muito relevante para o perfil de usuários que o PC-BSD se destina: o usuário doméstico típico.

Porém, um dos principais fatores de destaque do PC-BSD no que tange a facilidade de uso é o seu sistema de instalacão de aplicacões de terceiros, o PBI: Push Button Installer, ou Instalador ao Apertar do Botão. O PBI é um formato especial e exclusivo do PC-BSD. Apesar de podermos usar pacotes pré-compilados (pkg_add) ou compilar a aplicacão localmente com a Colecão de Ports do FreeBSD, o formato padrão não é nenhum dos dois, e sim o PBI, que analisaremos agora em mais detalhes.

O Formato PBI – Visão Superficial

O formato de pacotes do instalador PBI é simples, parte do princípio que um PBI vai sempre instalar a aplicacão, todas as bibliotecas e dependências dessa aplicacão, em um compartimento único e isolado. Dessa forma não há conflitos de bibliotecas, não há também conflitos entre versões de dependências, nem há dependência da própria ABI nativa do sistema operacional.

A idéia por trás do conceito que o PBI trás é de um instalador que vai instalar aplicacões que vão rodar em qualquer versão do PC-BSD, e principalmente, que vai continuar plenamente funcional mesmo após atualizacões mesmo as mais radicais, com troca plena de ABI, com tanto que uma compatibilidade mínima seja mantida entre o sistema novo e suas versões anteriores – em kernel, os COMPAT_FREEBSD4, COMPAT_FREEBSD5, COMPAT_FREEBSD6, COMPAT_FREEBSDX;

Para isso, os arquivos com extensão .pbi são interpretados pelo PC-BSD como instalacão e são considerados executáveis. Esses executáveis são divididos essencialmente em quatro partes:

A primeira é a biblioteca de carregamento (o loader) que permite que o .pbi seja interpretado como um executável ELF. Ou seja são os Elf Loader Headers. A segunda parte contém embarcado o ícone da aplicacão que será instalada. A terceira camada tem as directivas e dados de configuracão do .pbi que identificam o que, onde e como será instalado. E finalmente a quarta etapa, são todos os dados da aplicacão, biblitecas e dependências, bem como os scripts que serão instalados.

O produto final de um arquivo .pbi é um executável auto-instalável:

eksffa@pcbsd% file JavaJRE1.6.0-PV0.pbi
JavaJRE1.6.0-PV0.pbi: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700109), dynamically linked (uses shared libs), FreeBSD-style, not stripped

eksffa@pcbsd% brandelf ./JavaJRE1.6.0-PV0.pbi
File ‘./JavaJRE1.6.0-PV0.pbi’ is of brand ‘FreeBSD’ (9).

Que de fato, é linkado dinamicamente apenas a própria ABI nativa (libc):

eksffa@pcbsd% ldd ./JavaJRE1.6.0-PV0.pbi
./JavaJRE1.6.0-PV0.pbi:
libc.so.7 => /lib/libc.so.7 (0x2807e000)

E cujo prefix de instalacão é fora do padrão FreeBSD, quebra a hier(7) e também a especificacão POSIX, e fica isolado em /Programs, não tocando qualquer outro arquivo em infra-estrutura fora dessa hierarquia.

Entendendo o funcionamento de um Produto Instalado a partir de um PBI

Aqui chega a parte onde a abordagem por trás de um produto resultante de um PBI instalado deve ser avaliado e entendido. Os binários e bibliotecas criados de um PBI são exatamente iguais os criados da compilacão genérica de um Ports ou a instalacão de um package binários. O produto é o mesmo, mas sua estrutura instalada e a forma como são carregados, é a diferencão.

O coracão por trás do PBI é uma idéia simples, completamente funcional, mas com alguns efeitos colaterais. Todo binário já acompanha suas dependências e suas bibliotecas, e esses são isolados, e utilizados exclusivamente para aquela aplicacão.

A estrutura da instalacão de um PBI se baseia que tudo será instalado no /Programs (que por sua vez é um link simbólico para o /usr/Programs); e abaixo dele temos algumas estruturas, nem sempre todas utilizadas. A saber:

Programs/
Programs/bin/
Programs/lib/
Programs/etc/
Programs/rc.d/
Programs/rc.conf
Programs/<aplicacão>/

Todas aplicacões são instaladas em /Programs/<aplicacão>/, que é sempre constituído da seguinte organizacão hierárquica:

Programs/<aplicacão>/bin/
Programs/<aplicacão>/.sbin/
Programs/<aplicacão>/autolibs/
Programs/<aplicacão>/share/
Programs/<aplicacão>/libs (lincado para ./autolibs local)

Além disso temos sempre scripts executáveis:

Programs/<aplicacão>/PBI.FirstRun.sh
Programs/<aplicacão>/PBI.RemoveScript.sh
Programs/<aplicacão>/PBI.RemoveScript2.sh
Programs/<aplicacão>/PBI.SetupScript.sh
Programs/<aplicacão>/PBI.UpdateURL.sh

Os executáveis acima são rotinas executadas na primeira inicializacão da aplicacão depois de instalada, um script auxiliar que permite ao sistema de atualizacão de PBI avaliar se há atualizacões do PBI em questão, e por último os outros são rotinas de deinstalacão da aplicacão.

O mais importante é o:

Programs/<aplicacão>/autolibs/

Isso porque nessa estrutura estão todas, todas a bibliotecas de que o binário depende, bem como suas dependências, sejam essas bibliotecas ou aplicacões. Ou seja quando a aplicacão é executava, o contexto de bibliotecas dinâmicas do linker do loader (carregador) é isolado, e as bibliotecas disponíveis para aquele contexto de execussão é exclusivamente as que estivirem em Programs/<aplicacão>/autolibs/.

Inteligente não? Dessa forma não importa a ABI do sistema operacional, nem importa que bibliotecas existam ou não, que dependências existam ou não no restante do sistema, pois tudo que a aplicacão precisa, ela já “traz consigo”. Quase como se fosse um binário compilado estáticamente. Porém, não é estático, é dinâmico, e apesar de em disco haver redundância de bibliotecas, em memória os objetos iguais são sempre alocados em memória shadow, não havendo o mesmo consumo de memória que haveria se fossem todas aplicacões estáticamente compiladas.

O binário de inicializacão real (o verdadeiro produto da instalacão) fica disponível em:

Programs/<aplicacão>/bin/

Porém, o ambiente de execussão desse binário acontece através do que fica disponívem em:

Programs/bin/<aplicacão>

Que por sua vez é um link simbólico, que se referencia a um shell script disponível em:

Programs/<aplicacão>/.sbin/

E ai sim, esse shell script é onde fica a sacada, o pulo do gato do isolamento de contexto de bibliotecas. Vejamos um exemplo prático, o amsn instalado, instala um arquivo .desktop no Desktop, que é o link para a aplicacão, vejamos:

[Desktop Entry]
Name=aMSN
Exec=/Programs/aMSN0.97.2_1/.sbin/amsn
Type=Application
Path=/Programs/aMSN0.97.2_1/
Icon=/Programs/aMSN0.97.2_1/amsn.png

Ou seja ao clicar nesse ícone, é executado o  /Programs/aMSN0.97.2_1/.sbin/amsn, que por sua vez é um link simbólico para um shell script:

% ls -l /Programs/bin/amsn
lrwxr-xr-x  1 root  wheel  33 10 Dez 21:11 /Programs/bin/amsn -> /Programs/aMSN0.97.2_1/.sbin/amsn

O Executável de Inicializacão da Aplicacão

O shell script que faz o isolamento do contexto das bibliotecas dinâmicas e carrega a aplicacão pode ter algumas variacões, mas a essência geral é a seguinte:

A variável de ambiente LD_LIBRARY_PATH é populada, e seu único conteúdo é o Programs/<aplicacão>/autolibs/ ; com essa variável definida assim, o binário é executado em Programs/<aplicacão>/bin/<aplicacão>. Dessa forma qualquer biblioteca ou dependência que o binário precisa, só tem o Programs/<aplicacão>/autolibs/ onde carregar. Esse é o coracão por trás do ambiente instalado por um PBI.

Outros arquivos podem ser necessários, caso em que outras variáveis são populadas permitindo acesso as demais estruturas. Mas normalmente são apenas arquivos de referência de configuracão e comportamento, como share, ícones, configuracões padrão, diretivas de controle, etc.

Seguindo o estudo vamos analisar o que temos para iniciar o amsn:

#!/bin/sh
# Auto-Generated by PC-BSD
PATH=”/Programs/aMSN0.97.2_1/bin:$PATH”; export PATH
LANG=”`grep ^Language= ~/.kde/share/config/kdeglobals | cut -d “=” -f2`”; export LANG
LD_LIBRARY_PATH=”/Programs/aMSN0.97.2_1/autolibs/” ; export LD_LIBRARY_PATH
STDLOG=”${HOME}/.$$stdout”
STELOG=”${HOME}/.$$stderr”
(((( /Programs/aMSN0.97.2_1/bin/amsn  “$@” || /PCBSD/bin/CrashHandler “bin/amsn” “${STDLOG}” “${STELOG}” ) | tee $STDLOG) 3>&1 1>&2 2>&3 | tee $STELOG) 3>&1 1>&2 2>&3)

rm $STDLOG >/dev/null 2>/dev/null
rm $STELOG >/dev/null 2>/dev/null

É esse o esqueleto padrão. Podem haver variacões, e de fato a infra-estrutura do PBI permite que hajam, para satisfazer os todos possíveis perfis de necessidade de aplicacões. Mas as variacões são apenas uma repeticão da idéia geral acima.

Avaliacão da Abordagem PBI

As impressões sobre a abordagem acima são as mais variadas. Sobre o PBI, já tivemos opinião de desenvolvedores Red Hat que mantém o padrão RPM, já tivemos opiniões de empacotadores Debian acostumados com os formatos de pacotes do Debian e toda a (bem criteriosa e inteligente, diga-se de passagem) estrutura de pacotes do Debian, e a opinião de Port Managers do Projeto FreeBSD, bem como mantenedores do PkgSrc.

De forma geral todos acham a idéia inteligente, porém, inadequada. O motivo é claro, ninguém gosta de ver tamanha redundância de bibliotecas e dependências como os PBI instalam. Porém, todos concordam, que poucas abordagens tem resultado tão prático e funcional. E acima de tudo, essa é a única abordagem livre de conflitos e problemas de dependências.

Efeitos Colaterais

Pro usuário final, porém, as consequências negativas da abordagem do PBI são duas: os PBI de forma geral são maiores do que poderiam ser, o download tem que trazer junto todas as dependências e bibliotecas que, de certa forma, podem já estar presentes no autolibs/ de alguma outra aplicacão ou na própria base do sistema operacional.

A segunda consequência é o espaco em disco. A abordagem dos PBI ocupa muito mais espaco em disco exatamente devido a essa redundância de bibliotecas e dependências. Em minhas análises, um conjunto simples de aplicacões, Firefox, aMSN, OpenOffice e Java, o consumo de espaco em disco é 34% superior com PBI do que instalado por pacote (package) pré-compilado. Se comparado com aplicacões compiladas localmente e com grande nível de customizacão de Build Time a diferenca pode ser ainda maior.

Resultados Obtidos pela Abordagem PBI

Os resultados conseguidos com essa abordagem porém, são os melhores possíveis: facilidade de uso, efetividade, e um resultado final sempre funcional com virtualmente nenhuma chance de problemas, conflitos ou falhas de dependência. No geral pesando as desvantagens do maior espaco em disco, as vantagens justificam a popularizacão do formato PBI por usuários típicos do PC-BSD.

fonte: fug-br  –  Por P. Tracanelli (FreeBSD Brasil)