Empaquetado de software con RPM, Parte 2: Actualización y desinstalación de software

Con este segundo artículo de una serie de tres partes sobre RPM Package Manager, aprenda a usar RPM para actualizar y desinstalar software en su sistema Linux. Esta serie reemplaza a una serie previa sobre RPM escrita por Dan Poirier).

Comparta su experiencia: ¿Cuáles son sus trucos RPM favoritos? Agregue sus comentarios a continuación.

Martin Streicher, Software Developer, Pixel, Byte, and Comma

author photo - martin streicherMartin Streicher trabaja como desarrollador independiente para Ruby on Rails y anteriormente fue el Editor en Jefe de Linux Magazine. Martin posee una Licenciatura en Ciencias de la Computación de la Universidad de Purdue, y se ha dedicado a la programación de sistemas similares al UNIX desde el año 1986. En su tiempo libre, colecciona obras de arte y juguetes..


Nivel de autor contribuyente en developerWorks

15-01-2010

En la industria de las telecomunicaciones, el concepto del "último kilómetro" (en inglés, "last mile") se refiere a la infraestructura, la construcción, los costos y las complicaciones inherentes a la entrega de un servicio a una gran cantidad de consumidores. Un proveedor de televisión por cable puede conectar con suma facilidad un extremo del país con otro vía satélite; sin embargo, obtener los derechos de servicio, cavar las zanjas e instalar el cableado para conectar a todos los hogares y empresas clientes es una misión mucho más compleja y onerosa. Para algunos proyectos, el último kilómetro— puede ser sólo el nombre del concepto — ya que ese último kilómetro podría representar una distancia interminable.

Otras industrias enfrentan desafíos equivalentes al último kilómetro del sector de telecomunicaciones. Uno tras otro, los supermercados minoristas fracasan en sus ventas online, principalmente porque ese último kilómetro resulta muy oneroso. El Servicio Postal de Estados Unidos continúa sufriendo grandes pérdidas en el último kilómetro de la entrega de correspondencia (literalmente). Los desarrolladores de software también deben enfrentar el último kilómetro. Un software generado no es más que una serie de unos y ceros hasta su implementación. A nivel conceptual, la instalación es una tarea sencilla pero, como sucede con la entrega de vinos, bananas, sobres y un sinnúmero de productos, el gran desafío está en los pequeños detalles.

El primer artículo de esta serie le presentó a RPM, un popular sistema de entrega de software. RPM viene incluido en muchas distribuciones de Linux y se utiliza ampliamente para implementar software comercial y de código abierto — por ejemplo, variantes de Red Hat Linux y Fedora Core Linux. El primer artículo de esta serie también mostró cómo construir, empaquetar e instalar una aplicación desde la fuente y transformarla en un sistema limpio.

Continuando con el análisis profundo de RPM y sus muchos usos, este artículo se centra en la actualización y la desinstalación de software existente. El tercer y último artículo desarrollará los escenarios menos frecuentes, como la colocación de parches en el código fuente y su distribución.

Información esencial sobre actualizaciones

La instalación de software por primera vez es el caso de implementación más sencillo. En este caso, el sistema meta está libre de daemons, binarios, archivos de configuración y/o archivos de datos de paquetes. Por lo tanto, una primera instalación no tiene por qué detener el progreso del trabajo o las tareas de actualización, restauración y posible combinación de archivos.

Sin embargo, si el sistema meta posee instalada una versión previa/actual del software o si el software está entrelazado con otros códigos y servicios, deberá tener especial cuidado para que su RPM mantenga el correcto funcionamiento de la configuración de trabajo. Probablemente sea necesario detener procesos, intercambiar o conservar archivos y reiniciar aplicaciones luego de copiar el código nuevo al sistema. Desde ya, no siempre es posible mantener la compatibilidad con versiones anteriores. En instancias como esta, su RPM deberá efectuar la menor cantidad de cambios posibles para mantener la funcionalidad y protección del sistema. En algunos casos, podría requerirse de códigos elaborados para interpretar configuraciones antiguas y renovarlas.

RPM proporciona cuatro hooks para inyectar comandos en secuencias de instalación y desinstalación; dos para cada tipo de secuencia. Todos los hooks se ejecutan en el sistema meta y suelen ser suficientes para cumplir con la mayoría de las tareas de mantenimiento. Estos cuatro hooks son:

  • Todos los comandos listados en el hook %pre se ejecutan antes de instalar su paquete.
  • Los comandos en el hook %post se ejecutan después de instalar su paquete.
  • El comando en el hook %preun se ejecuta antes de que su paquete se elimine del sistema.
  • Los comandos en el hook %postun se ejecutan después de que su paquete se elimine del sistema.

Por consiguiente, el orden de operaciones a seguir durante una actualización es:

  1. Ejecutar la sección %pre del RPM a instalar.
  2. Instalar los archivos que proporciona el RPM.
  3. Ejecutar la sección %post del RPM.
  4. Ejecutar %preun del paquete antiguo.
  5. Eliminar todo archivo antiguo que no haya sido sobrescrito por la nueva versión. (Este paso elimina archivos no requeridos por el nuevo paquete).
  6. Ejecutar el hook %postun del paquete antiguo.

Puede desconfiar de las instrucciones proporcionadas en los pasos 4 y 6 y esto es comprensible: si usted se encuentra actualizando un paquete, ejecutar los hook de desinstalación de la versión antigua podría revertir algunas tareas de los pasos 1 a 3. De hecho, sin ninguna condición establecida, los hooks de desinstalación de la versión antigua destruirían la nueva versión. Para evitar la destrucción involuntaria por superposición, RPM muestra un argumento (un indicador) para cada hook. El valor del indicador permite visualizar qué operación se está realizando:

  • Si el primer argumento correspondiente a %pre es 1, la operación RPM es una instalación inicial. Si el argumento correspondiente a %pre es 2, la operación es una actualización de una versión existente.
  • De la misma manera, los argumentos correspondientes a %post son 1 y 2 para una nueva instalación o una actualización, respectivamente. (aquí tampoco se ejecutan %pre y %post durante desinstalaciones).
  • Si el primer argumento correspondiente a %preun y %postun es 1, se trata de una actualización.
  • Si el primer argumento correspondiente a %preun y %postun es 0, se trata de una desinstalación.

Agregue lógica alrededor de cada hook para probar el valor del argumento y ejecute el código correcto. Predeterminadamente, cada hook se interpreta como un script de shell Bourne (generalmente, /bin/sh), a menos que nombre otro intérprete de scripts, como Perl. A continuación se muestra un hook %pre condicional escrito para el shell Bourne:

%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

El siguiente es el mismo hook, pero esta vez escrito para Perl. Para usar otro intérprete de scripts de hooks, especifique la opción -p y nombre la ruta totalmente apta al intérprete.

%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" }

Si especifica un intérprete que no existe en la máquina meta, la utilidad RPM generará un error similar a este:

$ 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

Si el administrador de sistemas del sistema meta visualiza este mensaje, deberá instalar el RPM para la dependencia y reintentar la instalación.


Atención con los activadores

En general, los RPM instalan un único paquete que no requiere de demasiados elementos de otros paquetes. Normalmente, los RPM solamente poseen requisitos previos o requisitos conjuntos y funcionan en aislamiento. Sin embargo, algunos paquetes se apartan de la regla general y afectan a otros.

Por ejemplo, algunos editores de textos son extensibles: agregando un paquete complementario a Ruby, el editor destaca la sintaxis de este lenguaje de programación. Si el editor se instala primero y luego se instala su complemento, la nueva característica surgirá de la manera esperada. Ahora bien, ¿qué sucedería si se instala primero el complemento — (por ejemplo, porque la extensión permite el uso en otros editores) — y luego se realiza la instalación del editor? Idealmente, la característica se agregaría sin problemas. Esta es la función que cumple el activador RPM.

Los RPM pueden adjuntar un activador a otro paquete para que realice una o más tareas si el paquete nombrado se instala o desinstala después de instalar su paquete. Los activadores son simplemente scripts, iguales a los que escribimos para %pre o %post. Incluso es posible nombrar un intérprete alternativo, si así lo desea.

  • El script %triggerin se ejecuta cuando se realiza la instalación del paquete nombrado.
  • %triggerun se ejecuta cuando se realiza la desinstalación del paquete nombrado.
  • El script %triggerpostun se ejecuta después de la desinstalación del paquete nombrado.

Por ejemplo, si usted quisiera ejecutar un script e instala Ruby con el paquete ya instalado en su sistema, podría escribir el siguiente código:

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

La opción -p es opcional. Deberá ingresar -- (dos guiones) y el nombre del paquete que desea monitorear.

Tomando en cuenta las copias, los hooks y los activadores, la siguiente sería la ejecución ordenada de las acciones para la instalación de un nuevo paquete llamado N. (La versión anterior de este paquete se denomina n.)

  1. Ejecutar el script %pre de N
  2. Copiar los archivos nuevos de N al sistema de archivos.
  3. Ejecutar el script %post de N
  4. Ejecutar todos los activadores de instalación (los marcados como %triggerin en otros paquetes) que se activaron con la instalación de N.
  5. Ejecutar todos los activadores de instalación de N.
  6. Ejecutar todos los activadores de desinstalación (%triggerun) de n
  7. Ejecutar todos los activadores de desinstalación (de otros paquetes) que se activaron con la desinstalación de n.
  8. Ejecutar el hook %preun de n.
  9. Eliminar todo archivo que no se haya sobrescrito con la instalación de N.
  10. Ejecutar todos los activadores de desinstalación (%triggerpostun) de n.

La instalación de software puede ser una tarea compleja, pero los hooks y activadores se ajustan prácticamente a todos los escenarios. Una advertencia: no intente interactuar con otro usuario mientras realiza cualquier paso del proceso. RPM está diseñado para permitir instalaciones en lote, durante las cuales no es necesaria la participación de usuarios. Si un paquete RPM se detiene durante la instalación, hace una pregunta y nadie la contesta, la instalación aparentemente se pausará.


Variables RPM

Los archivos RPM pueden tornarse largos y complejos. Así como usamos variables como método abreviado en aplicaciones, es posible usar las variables como marcadores de posición en un archivo de especificaciones RPM.

Por ejemplo, podemos definir una variable en la parte superior del archivo de especificaciones y referirnos a ella usando %{variable_name} en todo el archivo — e incluso en los scripts de %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

Más RPM en el futuro

Si usted desarrolla software para máquinas UNIX® y Linux, escribir el instalador podría resultar una tarea engorrosa. Afortunadamente, no es necesario escribir la tecnología de instalación desde cero. RPM es un formato muy capaz y ampliamente soportado para la distribución de software. Gracias a RPM, el "último kilómetro" es algo muy simple.

Recursos

Aprender

Obtener los productos y tecnologías

  • Obtenga más información y descargue rpmlint.
  • Obtenga más información y descargue Easy RPM Builder.
  • Con el software de prueba de IBM, disponible para su descarga directa desde developerWorks, construya su próximo proyecto de desarrollo en Linux.

Comentar

  • Participe en la comunidad My developerWorks. Conéctese con otros usuarios developerWorks y conozca los blogs, foros, grupos y wikis orientados a los desarrolladores.

Comentarios

developerWorks: Ingrese

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


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

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

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=468347
ArticleTitle=Empaquetado de software con RPM, Parte 2: Actualización y desinstalación de software
publish-date=01152010