Pacote de software com RPM, Parte 2: Atualizando e desinstalando software

Neste segundo artigo de uma série dividida em três partes sobre o RPM Package Manager, saiba como usar o RPM para atualizar e desinstalar software no seu sistema Linux. (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.


nível de autor Contribuidor do
        developerWorks

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

No setor de telecomunicações, a "última milha" descreve a infraestrutura, a construção, os custos e as complicações inerentes ao fornecimento de um serviço a um grande número de consumidores. Um provedor a cabo pode achar fácil ligar uma ponta do país a outra via satélite; entretanto, é algo muito diferente e oneroso ganhar os direitos de abrir caminho, abrir valas e passar cabos para atender a cada lar e a cada empresa. Para se ter algumas ideias, a última milha—uma noção não necessariamente de distância exata—pode também ser composta por várias milhas.

Outros setores enfrentam o equivalente de última milha de telecom. Mercearias distantes muitas vezes não têm acesso à Internet porque a última milha é muito cara. O serviço de correios dos Estados Unidos continua sofrendo perdas ao fazer entregas de cartas (muitas vezes literalmente) na última milha. Os desenvolvedores de software enfrentam o problema da última milha também. Quando o software for criado, ele será apenas um conjunto de vários zeros e uns até ser implementado. Conceitualmente, a instalação é fácil; mas com o fornecimento de fios, bananas e envelopes, o problema está nos detalhes.

O primeiro artigo desta série apresentou o RPM, um sistema de fornecimento de software conhecido. É possível encontrar RPM em muitas distribuições Linux e, como tal, é amplamente usado para implementar software comercial e software livre—por exemplo, variantes de Red Hat Linux e Fedora Core Linux. O primeiro artigo também mostrou como criar, criar o pacote e instalar um aplicativo do zero em um sistema limpo.

Continuando a investigação em RPM e seus muitos usos, este artigo aprofunda-se na atualização e na desinstalação do software existente. O terceiro e último artigo examinará os cenários mais comuns, como patch e distribuição de código de origem.

Fatos concretos sobre atualizações

A instalação de software pela primeira vez é o caso mais simples de implementação. O sistema de destino não tem os daemons do pacote, os binários, os arquivos de configuração e/ou os arquivos de dados, portanto, uma primeira instalação não precisa interromper o trabalho em andamento ou fazer o backup de arquivos, restaurá-los e possivelmente mesclá-los.

Entretanto, se o sistema de destino tiver uma versão anterior ou atual do software ou se o software for vinculado a outros códigos e serviços, seu RPM deverá ter cuidado especial para manter uma configuração executável. Pode ser preciso parar os processos, trocar ou preservar os arquivos e reiniciar os aplicativos após o novo código ter sido copiado para o sistema. Claro, nem sempre é possível manter a compatibilidade com versões anteriores. Nessas instâncias, seu RPM deve efetuar o menor número possível de alterações para manter o sistema funcional e protegido. Em alguns casos, isso pode significar elaborar scripts para interpretar configurações antigas e transformá-las em configurações novas.

RPM oferece quatro ganchos para injetar comandos nas sequências de instalação e desinstalação: dois para instalação e dois para desinstalação. Todos os ganchos são executados no sistema de destino e geralmente são suficientes para a maioria das tarefas domésticas. Esses quatro ganchos são:

  • Todos os comandos listados no gancho %pre são instalados antes de o seu pacote ser instalado.
  • Os comandos no gancho %post são executados após o seu pacote ter sido instalado.
  • O gancho %preun é executado antes de o seu pacote ser removido do sistema.
  • Os comandos no gancho %postun são executados após o seu pacote ser removido do sistema.

Consequentemente, a ordem das operações durante uma atualização é:

  1. Executar a seção %pre do RPM sendo instalado.
  2. Instalar os arquivos fornecidos pelo RPM.
  3. Executar a seção %postdo RPM.
  4. Executar o %preun do pacote antigo.
  5. Excluir todos os arquivos antigos não sobrescritos pela versão mais nova. (Essa etapa exclui arquivos que o novo pacote não solicita.)
  6. Executar o gancho %postun do pacote antigo.

As Etapas 4 e 6 podem parecer um pouco suspeitas, e por um bom motivo: Se estiver atualizando um pacote, a execução dos ganchos de desinstalação da versão mais antiga poderá desfazer algumas partes ou tudo das etapas 1 a 3. De fato, sem condições, os ganchos de desinstalação da versão mais antiga poderão destruir a versão mais recente. Para impedir ataques contínuos não-intencionais, o RPM passa a cada gancho um argumento, um sinalizador. O valor do sinalizador indica qual operação está sendo executada:

  • Se o primeiro argumento para %pre for 1, a operação de RPM será uma instalação inicial. Se o argumento para %pre for 2, a operação será uma atualização de uma versão existente para uma nova.
  • Da mesma forma, os argumentos para um %post são 1 e 2 para uma nova instalação e uma atualização, respectivamente. (Novamente, %pre e %post não são executados durante uma desinstalação.)
  • Se o primeiro argumento para %preun e %postun for 1, a ação será uma atualização.
  • Se o primeiro argumento para %preun e %postun for 0, a ação será uma desinstalação.

Reúna cada um dos seus ganchos com lógica para testar o valor do argumento e executar o código correto. Por padrão, cada gancho é interpretado como um script de Bourne shell (em geral, /bin/sh), a menos que você nomeie outro interpretador de scripts, como Perl. Aqui, é um gancho %pre condicional escrito para o Bourne shell:

%pre 
if [ "$1" = "1" ]; then
  # Perform tasks to prepare for the initial installation
elif [ "$1" = "2" ]; then
  # Perform whatever maintenance must occur before the upgrade begins
fi

E aqui é o mesmo gancho, embora escrito para Perl. Para usar outro interpretador para o seus scripts de gancho, especifique a opção -p e dê um nome de caminho totalmente qualificado para o interpretador.

%pre -p /usr/bin/perl
if ( $ARGV[0] == 1 ) {
  print "Preparing for initial install...\n"
} 
elsif ( $ARGV[0] == 2 ) {
  print "Preparing to upgrade software...\n"
}

Se você especificar um interpretador que não existe na máquina de destino, o utilitário RPM gerará um erro semelhante a isto:

$ sudo rpm -i RPMS/i386/wget-1.12-1.i386.rpm
error: Failed dependencies:
	/usr/bin/perl is needed by wget-1.12-1.i386

Se o administrador de sistema do sistema de destino vir uma mensagem desse tipo, ele deverá instalar o RPM para a dependência e tentar a instalação novamente.


Permanecer alerta com acionadores

Em geral, um RPM instala um único pacote que precisa pouco de outros pacotes. Em geral, um RPM tem pré-requisitos ou correquisitos, mas, por outro lado, está isolado. Dito isso, há aqueles pacotes que afetam outros.

Por exemplo, alguns editores de texto são extensíveis: Adicione um pacote complementar para Ruby, digamos, e o editor poderá selecionar a sintaxe dessa linguagem de programação. Se o editor for instalado primeiro, seguido por seu complemento, o novo recurso aparecerá conforme o esperado. Mas, e se o complemento for instalado primeiro—digamos, porque a extensão funciona para vários editores—e for seguido pela instalação do editor? O ideal é que o recurso seja adicionado exatamente da mesma forma. Essa é a noção de um acionador de RPM.

Um RPM pode anexar um acionador a outro pacote para executar uma ou mais tarefas se o pacote nomeado for instalado ou desinstalado após a instalação do seu pacote. Cada acionador é apenas um script, como os escritos para %pre ou %post. É possível até mesmo nomear um interpretador alternativo, se você preferir.

  • Um script %triggerin é executado quando o pacote nomeado é instalado.
  • %triggerun é executado quando o pacote nomeado é desinstalado.
  • Um script %triggerpostun é executado após o pacote nomeado ser desinstalado.

Por exemplo, se quiser executar um script caso Ruby seja instalado após o seu pacote ter sido armazenado em um sistema, você poderá escrever:

%triggerin -p /usr/bin/perl -- ruby
# React to the addition of Ruby

A opção -p é opcional. É preciso digitar -- (dois hífens) e depois nomear o pacote que deseja monitorar.

Com cópias ganchos e acionadores em mente, aqui está a ordem de execução dessas ações durante a instalação de um novo pacote, N. (A versão anterior do pacote tem o nome n.)

  1. Execute o script %pre de N.
  2. Copie os novos arquivos de N para o sistema de arquivos.
  3. Execute o script %post de N.
  4. Execute todos os acionadores de instalação (os marcados como %triggerin em outros pacotes) definidos pela instalação de N.
  5. Execute todos os acionadores de instalação de N.
  6. Execute todos os acionadores de desinstalação de n (%triggerun).
  7. Execute todos os acionadores de desinstalação (os encontrados em outros pacotes) definidos pela desinstalação de n.
  8. Execute o gancho de %preun de n.
  9. Remova todos os arquivos não sobrescritos pela instalação de N.
  10. Execute todos os acionadores de desinstalação (%triggerpostun) encontrados em n.

A instalação do software pode ser complexa, embora os ganchos e os acionadores possam acomodar praticamente qualquer cenário. Uma advertência: não tente interagir com um usuário durante qualquer etapa do processo. O RPM foi projetado para permitir instalações em lote, durante as quais nenhum usuário está necessariamente presente. Se um pacote RPM for pausado durante uma instalação para fazer uma pergunta e ninguém vir a pergunta, a instalação aparentemente será interrompida.


Variáveis de RPM

Os arquivos do RPM podem se tornar grandes e complexos. Como você usa variáveis como abreviação em aplicativos, é possível utilizar variáveis como marcadores em um arquivo de especificação RPM.

Por exemplo, é possível definir uma variável próximo ao topo do seu arquivo de especificação e se referir a ela usando %{variable_name} em toda parte—e mesmo em seus scripts para %pre:

%define foo_dir /usr/lib/foo

%install
cp install.time.message $RPM_BUILD_ROOT/%{foo_dir}

%files
%{foo_dir}/install.time.message

%post
/bin/cat %{foo_dir}/install.time.message

Mais RPMs no futuro

Se você desenvolver software para máquinas UNIX® e Linux, a gravação no instalador poderá ser uma tarefa fácil. Felizmente, não é preciso escrever a tecnologia da instalação do zero. RPM é um formato com amplo suporte e competente para a distribuição de software. Ele torna a "última milha" uma caminhada no parque.

Recursos

Aprender

Obter produtos e tecnologias

  • Saiba mais e faça o download de rpmlint.
  • Saiba mais e faça o download de Easy RPM Builder.
  • Com o software de teste IBM, disponível para download diretamente no developerWorks, faça seu próximo projeto de desenvolvimento em Linux.

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=471579
ArticleTitle=Pacote de software com RPM, Parte 2: Atualizando e desinstalando software
publish-date=03042010