Empacotando software com RPM, Parte 1: Construindo e distribuindo pacotes

Em seu primeiro artigo de uma série de três partes do RPM Package Manager, aprenda a usar o RPM não apenas para instalar software e arquivos relacionados, mas para fazer pacotes de quase tudo, desde scripts de sistema para código-fonte até documentação. (Esta série substitui uma série anterior sobre RPM escrita por Dan Poirier.)

Compartilhe seu conhecimento: Quais são os seus truques favoritos de RPM? Inclua seus comentários abaixo.

Martin Streicher, Editor in Chief, Linux Magazine

Martin Streicher é um desenvolvedor freelancer Ruby on Rails e antigo Editor-Chefe da Linux Magazine. Martin possui um grau de Mestre em Ciência da Computação pela Universidade de Purdue e tem programa para sistemas UNIX desde 1986. Ele coleciona artes e brinquedos.



04/Mar/2010 (Primeira publicação 04/Mar/2010)

O benefício principal de software de código aberto é, como seu nome implica, o acesso aos mecanismos internos de um aplicativo. Dada a fonte, é possível estudar como funciona um aplicativo; mudar, melhorar e ampliar sua operação; emprestar e redefinir a finalidade do código (de acordo com os limites da licença do aplicativo); e portar o aplicativo a plataformas novas e emergentes.

Entretanto, tal acesso liberal nem sempre é desejado. Por exemplo, um usuário pode não querer o ônus de construir a partir do código fonte. Em vez disso, pode simplesmente querer instalar o software bem como um aplicativo tradicional "shrink-wrapped": inserir mídia, executar setup, responder alguns prompts, e avançar. De fato, para a maioria dos usuários de computador, esse software pré-construído é preferido. O código pré-construído é menos sensível a ocorrências do sistema e, desse modo, mais uniforme e previsível.

Em geral, um aplicativo de fonte aberta pré-construído é chamado de um pacote e agrupa todos os arquivos binários, dados e configuração necessários para executar o aplicativo. Um pacote também inclui todas as etapas necessárias para implementar o aplicativo em um sistema, geralmente na forma de um script. O script pode gerar dados, iniciar e parar serviços do sistema, ou manipular arquivos e diretórios. Um script também pode realizar operações para atualizar software existente para uma nova versão.

Visto que cada sistema operacional possui sua idiossincrasia, um pacote é geralmente feito sob medida para um sistema específico. Além disso, cada sistema operacional fornece seu próprio gerenciador de pacote, um utilitário especial para adicionar e remover pacotes do sistema. Por exemplo, sistemas baseados em Debian Linux® usam o Advanced Package Tool (APT), enquanto os sistemas Fedora Linux usam o RPM Package Manager. O gerenciador de pacote impede instalações parciais e com falhas e "uninstalls" através da adição e remoção dos arquivos em um pacote atomicamente. O gerenciador de pacote também mantém um manifesto de todos os pacotes instalados no sistema e pode validar a existência de pré-requisitos e co-requisitos antecipadamente.

Se você é um desenvolvedor de software ou um administrador de sistemas, o fornecimento de seu aplicativo como um pacote torna as instalações, upgrades e manutenção muito mais fáceis. Aqui, você aprenderá como usar o popular RPM Package Manager para agrupar um utilitário. Para fins de demonstração, você agrupará o utilitário de rede wget, que baixa os arquivos da Internet. O utilitário wget é útil, mas não é comumente encontrado padrão em distribuições. (Um curl análogo é frequentemente incluído em distribuições). Esteja ciente de que é possível usar RPM para distribuir quase tudo —scripts, documentação e dados— e executar quase toda tarefa de manutenção.

Construindo o wget manualmente

O utilitário wget, como muitos outros aplicativos de fonte aberta, pode ser construído manualmente. Compreender esse processo é o ponto de partida para agrupar o wget em um pacote. De acordo com a convenção geral, a construção do wget exige quatro etapas:

  1. Baixar e retirar a fonte do pacote.
  2. Configurar a construção.
  3. Construir o código.
  4. Instalar o software.

É possível baixar a última versão do código fonte do wget de ftp.gnu.org (vide Recursos para o link; no fim de setembro de 2009, a versão atual do wget era 1.12). O restante das etapas requer a linha de comando, conforme mostrada na Listagem 1.

Listagem 1. Instalando o wget

Clique aqui para ver lista de códigos

                $ tar xzf wget-latest.tar.gz $ cd wget-1.12 $ ./configure
                            configure: configuring for GNU Wget 1.12 checking for a BSD-compatible install...
                            /usr/bin/install -c checking whether build environment is sane... yes checking for a
                            thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking
                            for mawk... no checking for nawk... no ... $ make $ sudo make install

./configure consulta o sistema e define opções de compilação adequadas para o hardware e software detectados. make compila o código e sudo make install instala o código em diretórios do sistema. Por padrão, os diretórios estão localizados em /usr/local, embora seja possível alterar o local pretendido com a opção --prefix=/some/full/path/name para ./configure.

Para converter este processo para RPM, coloque a fonte em um repositório e grave um arquivo de configuração para ditar onde encontrar a fonte a ser compilada e como construir e instalar o código. O arquivo de configuração, denominado de arquivo spec, é a entrada a um utilitário denominado rpmbuild. O arquivo spec e os binários são empacotados pelo rpmbuild em um RPM. Quando outro usuário baixa o seu RPM, o utilitário rpm lê o arquivo spec e instala o pacote de acordo com suas instruções pré-gravadas.


Construindo seu primeiro RPM

Antes de continuar, um pouco de precaução. No passado, os pacotes eram construídos por root, o superusuário, pois o root era o único usuário capaz de acessar o repositório do código-fonte do sistema. Entretanto, esta abordagem era potencialmente perigosa. Visto que o root pode alterar qualquer arquivo no sistema, era fácil alterar inadvertidamente um sistema em operação, adicionando arquivos estranhos ou remover arquivos importantes durante construções temporárias de um RPM. Mais recentemente, o sistema RPM foi alterado para permitir que qualquer usuário construa RPMs em um diretório principal. Construir um RPM sem os privilégios de root impede alterações nos arquivos do sistema principal. Aqui é mostrada a abordagem mais moderna.

Para construir um RPM, é preciso:

  • Definir uma hierarquia de diretório de acordo com as especificações de rpmbuild.
  • Colocar seu código-fonte e arquivos suplementares nos locais adequados na hierarquia.
  • Criar seu arquivo spec.
  • Construir o RPM. Opcionalmente, é possível construir um RPM fonte para compartilhar seu código-fonte com outros.

Para iniciar, construa a hierarquia. Em um diretório em seu diretório principal— a saber, $HOME/mywget— crie cinco subdiretórios:

  • BUILD. BUILD é usado como espaço de rascunho para compilar realmente o software.
  • RPMS. RPMS contém o RPM binário que o rpmbuild constrói.
  • SOURCES. SOURCES destina-se ao código-fonte.
  • SPECS. SPECS contém seu arquivo ou arquivos spec— um arquivo spec por RPM que desejar construir.
  • SRPMS. SRPMS contém o RPM fonte construído durante o processo.

No mínimo, será necessário o código-fonte em SOURCES e um arquivo spec em SPECS.

Copie sua fonte, idealmente agrupada como um tarball, no diretório SOURCES, conforme mostrado na Listagem 2. Se necessário, renomeie o tarball para incluir o número da versão do aplicativo para diferenciá-lo de outros. A convenção de nomes é pacote-versão.tar.gz. No caso de wget, seria usado:

Listagem 2. Copiando sua fonte

                $ cd ~ $ mkdir mywget $ cd mywget $ mkdir BUILD RPMS SOURCES
                            SPECS SRPMS $ cd SOURCES $ cp wget-latest.tar.gz . $ mv wget-latest.tar.gz
                            wget-1.12.tar.gz $ cd ..

A seguir, crie o arquivo spec. Um arquivo spec é apenas um arquivo de texto com uma sintaxe especial. A Listagem 3 mostra um exemplo de um arquivo spec.

Listagem 3. Arquivo spec de exemplo

Clique aqui para ver lista de códigos

                 # This is a sample spec file for wget %define _topdir
                        /home/strike/mywget %define name wget %define release 1 %define version 1.12 %define
                        buildroot %{_topdir}/%{name}-%{version}-root BuildRoot: %{buildroot} Summary: GNU
                        wget License: GPL Name: %{name} Version: %{version} Release: %{release} Source:
                        %{name}-%{version}.tar.gz Prefix: /usr Group: Development/Tools %description The GNU
                        wget program downloads files from the Internet using the command-line. %prep %setup
                        -q %build ./configure make %install make install prefix=$RPM_BUILD_ROOT/usr %files
                        %defattr(-,root,root) /usr/local/bin/wget %doc %attr(0444,root,root)
                        /usr/local/share/man/man1/wget.1

Vamos analisar o arquivo spec do início ao fim. As Linhas 1-5 definem um conjunto de variáveis de conveniência usadas em todo o restante do arquivo. As Linhas 7-15 definem uma série de parâmetros necessários usando o formulário parâmetro: valor. Como é possível ver na linha 7 e em outros lugares, as variáveis podem ser avaliadas e combinadas para produzirem o valor de uma configuração.

Os nomes de parâmetro são amplamente autoexplicativos, porém BuildRoot merecem alguma explicação para diferenciá-lo do diretório BUILD que você já criou. BuildRoot é um proxy para o diretório de instalação final. Em outras palavras, se wget for instalado em última instância em /usr/local/bin/wget e outros subdiretórios em /usr/local, tais como /usr/local/man para documentação, BuildRoot permanece como /usr/local durante o processo de construção de RPM. Uma vez definido o BuildRoot, é possível acessar seu valor usando a variável de ambiente RPM_BUILD_ROOT. Sempre é necessário definir BuildRoot em seu arquivo spec e verificar o conteúdo desse diretório para verificar o que será instalado pelo pacote.

Eis algumas dicas:

  • Não use ./configure --prefix=$RPM_BUILD_ROOT. Este comando constrói todo o pacote, assumindo que a localização final dos arquivos é o root de construção. É provável que isso causasse a falha de qualquer programa que necessitasse localizar seus arquivos instalados na hora de execução, pois quando seu RPM estiver finalmente instalado no sistema de um usuário, os arquivos não mais ficarão no root de construção—este é apenas um diretório temporário em seu sistema de construção.
  • Não inclua um caminho na definição de Fonte.
  • Versão e Release são especialmente importantes. A cada vez que alterar o código ou dados de seu aplicativo e disponibilizar um novo RPM, tenha certeza de incrementar os valores de Versão e Release para refletir alterações importantes e secundárias, respectivamente. Você pode considerar útil aumentar o número de release a cada vez que construir um RPM, mesmo se for para uso próprio, para manter as tentativas separadas.

A próxima seção inicia com %description. Aqui, é preciso fornecer uma descrição concisa porém clara do software. Esta linha é mostrada sempre que um usuário executa rpm-qi para consultar o banco de dados RPM. É possível explicar o que o pacote faz, descrever quaisquer avisos ou instruções de configuração adicional e mais.

As seções %prep, %build, e %install são as próximas, consecutivamente. Cada seção geral um script shell que é integrado no RPM e executa subsequentemente como parte da instalação. %prep prepara o código-fonte, tal como desempacotar o tarball. Aqui, %setup -q é uma macro %prep para desempacotar automaticamente o tarball nomeado em Fonte.

As instruções na seção %build devem parecer familiares. São idênticas às etapas usadas para configurar e iniciar a construção manualmente. A seção %install também é idêntica. Entretanto, enquanto o alvo da construção manual era o diretório real /usr/local de seu sistema, o alvo da instrução %install é ~/mywget/BUILD.

%files lista os arquivos que devem ser agrupados no RPM e opcionalmente define permissões e outras informações. Dentro de %files, é possível usar a macro %defattr para definir as permissões padrão, proprietário e grupo de arquivos no RPM; neste exemplo, %defattr(-,root,root) instala todos os arquivos detidos pelo root, usando quaisquer permissões encontradas quando o RPM os agrupou do sistema de construção.

É possível incluir arquivos múltiplos por linha em %files. É possível sinalizar os arquivos adicionando %doc ou %config à linha. %doc indica ao RPM que o arquivo é um arquivo de documentação, de modo que se um usuário instalar o pacote usando --excludedocs, o arquivo não é instalado. %config indica ao RPM que este é um arquivo de configuração. Durante upgrades, o RPM tentará evitar sobrescrever uma configuração cuidadosamente modificada de um usuário por um arquivo de configuração padrão empacotado por RPM.

Esteja ciente de que se você lista um nome de diretório em %files, o RPM inclui todo arquivo nesse diretório.


Acelerando o RPM

Agora que os seus arquivos estão no lugar e o seu arquivo spec está definido, é hora de construir o arquivo real RPM. Para construí-lo, use o aptly denominado utilitário rpmbuild:

 $ rpmbuild -v -bb --clean SPECS/wget.spec

Este comando usa o arquivo spec nomeado para construir um pacote binário (-bb para "construir binário") com saída excessiva (-v). O utilitário de construção remove a árvore de construção após os pacotes serem feitos (--clean). Se também desejava construir o RPM fonte, especifique -ba ("construir todos") em vez de -bb. (Vide a página principal rpmbuild para obter uma lista completa de opções.)

rpmbuild executa essas etapas:

  • Lê e analisa o arquivo wget.spec.
  • Executa seção %prep para desempacotar o código-fonte em um diretório temporário. Aqui, o diretório temporário é BUILD.
  • Executa a seção %build para compilar o código.
  • Executa a seção %install para instalar o código em diretórios na máquina de construção.
  • Lê a lista de arquivos da seção %files, os reúne, e cria um RPM binário (e arquivos RPM fonte, se você escolher).

Se você examinar seu diretório $HOME/mywget, encontrará um novo diretório nomeado wget-1.12-root. Este diretório é o proxy do destino alvo. Você também encontrará um novo diretório nomeado RPMS/i386, que, por sua vez, conterá seu RPM, nomeado de wget-1.12-1.i386.rpm. O nome do RPM reflete que esta é a versão wget 1.12 do processador i386.

Para verificar que o RPM contém os arquivos adequados, é possível usar o comando rpm, conforme mostrado na Listagem 4.

Listagem 4. Verificando os conteúdos RPM

Clique aqui para ver lista de códigos

                $ rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm missing
                            /usr/local/bin/wget .M....G. /usr/local/etc missing c /usr/local/etc/wgetrc .M....G.
                            /usr/local/share missing /usr/local/share/info missing d
                            /usr/local/share/info/wget.info missing /usr/local/share/locale missing
                            /usr/local/share/locale/be missing /usr/local/share/locale/be/LC_MESSAGES missing d
                            /usr/local/share/locale/be/LC_MESSAGES/wget.mo . . .

O comando rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm verifica o pacote contra os arquivos no sistema. Embora haja aparentemente muitos erros, cada um é uma pista de que os conteúdos do arquivo RPM estão corretos. Se você estiver esperando que um arquivo seja instalado e ele não aparecer na saída, ele não foi incluído no pacote. Nesse caso, revise o arquivo spec e certifique-se de que o arquivo esteja enumerado na seção %files.

Após ter verificado o RPM, é possível distribuir o arquivo aos parceiros de trabalho. Quando seus parceiros receberem o arquivo, eles devem executar rpm para instalar o wget em seus sistemas:

$ sudo rpm -i wget-1.12-1.i386.rpm

Outros usos do RPM

Esta breve introdução simplesmente arranha a superfície do que é possível com o RPM. Embora ele seja mais frequentemente usado para instalar software e arquivos relacionados, é possível empacotar quase tudo, de scripts de sistema para código-fonte até documentação. E como você verá na segunda parte desta série, também é possível usar o RPM para corrigir código-fonte, bem como reconstruir e reinstalar software. O formato de distribuição RPM é encontrado em muitos sistemas Linux e é o método preferido para instalar software binário em sistemas Red Hat e Fedora, entre outros.

Se construí-lo e empacotá-lo com RPM, ele virá.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Envolva-se na comunidade My developerWorks. Conecte-se com outros usuários do developerWorks enquanto explora os blogs, fóruns, grupos e wikis conduzidos por desenvolvedores.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=471550
ArticleTitle=Empacotando software com RPM, Parte 1: Construindo e distribuindo pacotes
publish-date=03042010