Como funciona: Pacotes RPM

A palavra RPM é um acrônimo recursivo que significa RPM Package Manager. De modo resumido ele é o equivalente aos pacotes .deb ou, se preferir, aos arquivos .exe do Windows, já que serve para instalar, desinstalar e atualizar arquivos e/ou softwares no sistema operacional.

Se você não gosta de história, pode pular a seção seguinte e ir direto para "Como funciona?".

Um pouco de história

No início da década de 90 já era evidente a necessidade de criar um "gerenciamento de pacotes" que fosse funcional e simples de usar. Até então, o método mais comum de instalação de softwares era a tradicional compilação e instalação direta pelo código fonte. Esse método, no entanto, era uma clara desvantagem porque excluía os usuários menos técnicos e fazia com que o sistema operacional tivesse quase ou nenhum controle sobre os softwares que eram instalados. Era comum que um software não pudesse mais ser desinstalado ou que, para garantir a desinstalação, o código fonte tivesse que ser mantido no sistema. Foi por isso que a Red Hat iniciou as pesquisas em busca de um método de gerenciamento de pacotes que fosse efetivo e simples.

RPP

Foi o nome do gerenciador de pacotes usado pelos primeiros Red Hats. O RPP foi a "musa inspiradora" para muitas das habilidades que o RPM de hoje em dia acabou herdando. Ele tinha uma utilização simples, bastando uma linha de comando para instalar um pacote; permitia a execução de scripts de pré e pós instalação/desinstalação; era capaz de fazer uma verificação dos pacotes para descobrir se alguma alteração nos arquivos tinha sido feita e salvava as informações do pacote (como descrição, versão, nome e listas de pacotes) em um banco de dados. Acabou não vingando porque, embora fosse relativamente eficiente, não conseguia trabalhar com o código fonte original dos softwares que instalava. Isso queria dizer que cada empacotador precisava hackear o software antes de empacotá-lo para que ele funcionasse bem com o RPP. Além disso, o RPP era incapaz de trabalhar com arquiteturas diferentes da x86... Embora tenha sido o gerenciador de pacotes RPP o grande diferencial da Red Hat no início da empresa, logo ficou claro que a limitação de não poder trabalhar com outras arquiteturas viria a se tornar um problema e por esse motivo, as pesquisas por um gerenciamento melhor de pacotes continuou.

PMS (Package Management System)

O PMS não foi desenvolvido pela Red Hat. Ao contrário, era desenvolvido por um grupo de desenvolvedores chefiados por Rik Faith que criaram a distribuição chamada Bogus Linux . Os pacotes PMS não eram muito bons porque usavam um banco de dados pobremente dsenhado e facilmente corruptível, também estavam limitados a apenas uma arquitetura mas introduziram o conceito de trabalhar diretamente com o código fonte do "upstream" (i.e. dos desenvolvedores originais). Qualquer mudança necessária para que o software funcionasse era aplicada por simples patches.

PM

Pouco depois, Rik Faith e Doug Hoffman , já contratados pela Red Hat, continuaram trabalhando num gerenciador de pacotes e desenvolveram o PM, que juntava todas as vantagens do RPP e do PMS. Infelizmente, herdou também as fraquezas dos dois gerenciadores de pacotes e possuía um banco de dados muito corruptível, além de, claro, continuar sendo compatível com somente um tipo de arquitetura.

RPM 1 (Finalmente)

Espelhando-se nas duas bem sucedidas tentativas de criação de gerenciamento (RPP e PMS), Marc Ewing e Erik Troan começaram a trabalhar em um terceiro gerenciador de pacotes que se chamaria RPM (Red Hat PackageManager).

Apesar de inspirado pelo RPP, PMS e PM, o RPM iria focar em resolver todos os problemas que esses gerenciadores antes não tinham conseguido resolver. A linguagem de programação escolhida foi o Perl, por ser fácil e rápido de programar.

Apesar do RPM 1 ter sido, relativamente, um êxito, apresentava diversos problemas:

• Era muito mais lento do que se tivesse sido escrito em C;
• O banco de dados era extremamente frágil e quebradiço, corrompendo-se à toa;
• Não era possível executar o gerenciador por um disquete, já que o fato de ser escrito em perl consumiria um espaço extra;
• Embora funcionasse em outras arquiteturas, o funcionamento ocorria com problemas
• O gerenciador de pacotes não era "expansível'. O que significava que qualquer mudança maior no código faria com que os pacotes anteriores se tornassem incompatíveis com as versões futuras.

RPM 2

Marc e Eric reescreveram o RPM totalmente, usando dessa vez a linguagem C. Essa decisão aumentou em muito a velocidade de execução do gerenciador de pacotes. Adicionalmente, o banco de dados foi redesenhado e permitia que as consultas fossem executadas em 1/10 do tempo que antes era tomado pelo RPM 1. Atualmente, o RPM está na versão 4.4.2.3.

Como funciona?

Um RPM é, na verdade, um meta pacote. Para facilitar o entendimento, pense nele como um pacote com diversos rótulos colados nele e que cada um desses rótulos contém um tipo de informação que é "interessante" que seu sistema saiba. O software que você deseja instalar está lá, compactado por um processo antigo e eficiente chamado cpio.

O que vem no RPM está "pré-compilado". Isso quer dizer que o software foi preparado em outra máquina, o resultado da compilação foi empacotado e tudo que você faz é instalar o software pronto para usar.

A anatomia de um pacote RPM é a seguinte:

1. O início do pacote RPM é a "guia" que ensina ao sistema operacional que se trata de um pacote RPM. Nessa seção existem cabeçalhos lidos pelo sistema que são importantes para o manuseio do pacote. Aqui cabe uma boa analogia com o GRUB.
2. Esta seção armazena assinaturas que garantem a autenticidade dos pacotes. É possível, por exemplo que um distribuidor assine seus RPMs com sua própria marca, que é identificada pelo sistema. Isso reforça a segurança e permite a um usuário instalar (ou não) somente softwares disponibilizados por distribuidores cuja assinatura seja confiável (como Fedora, Red Hat, Mandriva, Opensuse...).
3. Na terceira seção permanecem as informações como nome do software, versão, release, descrição, lista de arquivos, dependências... Essas entradas são armazenadas no banco de dados do RPM.
4. A quarta (e maior) seção contém, finalmente, os arquivos compactados. Na figura ela é representada por .tar.gz mas isso é meramente ilustrativo. Na verdade, o método de compressão é o cpio. Cada pacote RPM tem uma limitação de tamanho: 2 GB para sistemas 32 bits e 4 GB para sistemas 64 bits.

Agora que você já entende como é um pacote RPM, está pronto para descobrir o que ele faz. Não vou entrar aqui em detalhes de como criar um pacote, isso foge ao escopo do nosso artigo, no entanto, de qualquer forma, antes de botar a mão na massa para fazer um RPM é sempre bom entender como ele funciona.

Quando você instala um software qualquer com o ./configure, make e make install, ele verifica se seu sistema está ok para rodá-lo, busca as pastas corretas, gera os links, instala as páginas de manual e executa quaisquer outras operações necessárias. Num pacote RPM ocorre exatamente o mesmo, mas o software é enganado e acaba se instalando numa árvore de diretórios falsa chamada "fake root". A árvore falsa é exatamente igual á árvore do seu sistema operacional, mas é "vazia", sem nenhum outro software; tudo que existe nessa árvore falsa é o software que foi "enganado" e se instalou na árvore de diretórios falsa. Depois disso, o software que monta os RPMs (chamado RPMBuild) pega essa árvore falsa e a compacta dentro do pacote.

Durante a instalação do software que, agora, está dentro do RPM o software é descompactado e "colado" em cima da árvore de diretórios de verdade.

Como a árvore falsa e a árvore verdadeira são exatamente iguais, o resultado disso é que o RPM acrescenta o novo software com seus arquivos, links e documentações à árvore existente, algo muito parecido com um "copiar e colar" em larga escala.

Tudo que você instalou via RPM fica registrado num banco de dados SQLite que fica localizado em /var/lib/rpm (mas não tente abrir esse banco de dados diretamente, geralmente o resultado é amargo). Se seu RPM foi bem feito ele contém uma lista de todo e qualquer arquivo que foi copiado para o seu HD. Cabe ao programador do pacote (empacotador) dizer ao RPM o que ele está jogando no disco, caso contrário, um RPM mal feito, ao ser desinstalado, pode deixar lixo inútil para trás.

Um pacote RPM é, afinal, algo muito simples.

Posts relacionados:

1. Como um pacote RPM chega no YUM?
2. Como funciona? — Entradas nos menus
3. Meu primeiro RPM oficial
4. Cinco simples passos para fazer seu RPM