Contenido


Empaquetado de software con RPM, Parte 2

Actualización y desinstalación de software

Comments

Contenido de la serie:

Este contenido es la parte # de # de la serie: Empaquetado de software con RPM, Parte 2

Manténgase en contacto por contenidos adicionales de esta serie.

Este contenido es parte de la serie:Empaquetado de software con RPM, Parte 2

Manténgase en contacto por contenidos adicionales de esta serie.

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 para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

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