Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Capítulo 3. Construcción de paquetes personalizados

Algunas cosas podrían fallar al construir paquetes personalizados. También puede suceder cuando los paquetes son distribuidos e instalados a través de Red Hat Network.Este capítulo proporciona un resumen acerca de cómo construir paquetes que pueden ser distribuidos a través de Red Hat Network de una forma exitosa. Entre los temas tratados se incluyen las razones para utilizar RPM, la forma de construir paquetes para RHN y el modo de firmar correctamente los paquetes.

3.1. Cómo crear paquetes para Red Hat Network

Red Hat Network utiliza la tecnología Gestor de paquetes RPM (RPM) para determinar las adiciones y las actualizaciones de software que son aplicables a cada sistema cliente. Los paquetes obtenidos desde Red Hat Network están generalmente en el formato RPM. Sin embargo, imágenes ISO completas están disponibles a través de la pestaña Software del sitio web de Red Hat Network, pero no están disponibles en las instalaciones del Servidor satélite de RHN. Si su servidor Satélite tiene activado el soporte para Solaris, se puede utilizar el servidor Satélite para cargar paquetes Solaris a los canales personalizados utilizados por clientes de Solaris.
RPM es una herramienta que proporciona a los usuarios un método fácil para instalar, desinstalar, actualizar y verificar los paquetes de software. También le permite a los desarrolladores de software empaquetar el código fuente y las versiones compiladas de un programa para los usuarios y desarrolladores.

3.1.1. Beneficios de RPM

RPM ofrece las siguientes ventajas:
Fácil actualización
Al utilizar RPM se pueden actualizar componentes individuales de un sistema sin tener que reinstalarlo completamente. Cuando Red Hat lanza una nueva versión de Red Hat Enterprise Linux, los usuarios no tienen que reinstalar el sistema para poder actualizarlo. RPM permite la actualización inteligente, completamente automatizada de su sistema. Los archivos de configuración en paquetes son mantenidos a lo largo de actualizaciones para que los usuarios no pierdan las adaptaciones realizadas. No se necesitan archivos especiales de actualización para actualizar un paquete ya que el mismo RPM sirve para instalar y actualizar el paquete.
Consulta de paquetes
RPM proporciona opciones de consulta que permiten la búsqueda de paquetes o archivos a través de toda la base de datos de RPM. También se puede averiguar el paquete al que pertenece un archivo y el origen de éste. Los archivos contenidos en el paquete están en formato comprimido, con una cabecera binaria personalizada que contiene información útil sobre el paquete y su contenido. RPM consulta la cabecera de una forma rápida y fácil.
Verificación del sistema
Otra función es la habilidad de verificar paquetes. Si le preocupa que uno de los archivos del paquete haya sido borrado, puede verificar el paquete y revisar el estado de los archivos proporcionados. La verificación le notificará cualquier anomalía. Si existe algún error, puede reinstalar el archivo fácilmente. Los archivos de configuración se preservan durante la reinstalación.
Fuentes originales
Una de las principales metas de RPM es la utilización de fuentes de software originales, tal y como son distribuidas por los autores del software. Con RPM, las fuentes originales pueden ser empaquetadas, incluidos los parches que han sido usados más las instrucciones de construcción. Esta es una gran ventaja por varias razones. Por ejemplo, si se lanza una nueva versión del programa, no será necesario iniciar la compilación desde el principio. Si mira las coincidencias podrá ver lo que necesitaría hacer. Todas las instrucciones de construcción compiladas por defecto y los cambios realizados para que el software se construya adecuadamente son fácilmente visibles mediante esta técnica.
Mantener las fuentes originales puede parecer importante solo para los desarrolladores, pero también lo es para los usuarios finales.

3.1.2. Lineamientos de RPM de RHN

Una de las mayores fortalezas de RPM está en la capacidad de definir dependencias e identificar conflictos acertadamente. Red Hat Network confía en esta característica de RPM. Red Hat Network ofrece un entorno automatizado, lo cual significa que no se necesitará de intervención manual durante la instalación de un paquete. Así, al construir los RPM para ser distribuidos a través de Red Hat Network, es importante seguir estas reglas:
  1. Aprenda RPM. Es importante tener un conocimiento fundamental de las funciones brindadas por RPM para construir los paquetes apropiadamente. Para mayor información acerca de RPM, inicie con los siguientes recursos:
  2. Cuando construya un RPM para un canal hijo, construya el paquete en una instalación fresca de Red Hat Enterprise Linux de la misma versión que el canal hijo base. Asegúrese primero de aplicar todas las actualizaciones de Red Hat Network.
  3. El paquete RPM debería poder instalarse sin utilizar las funciones --force o --nodeps. Si usted no puede instalar en su sistema de construcción un RPM de una manera limpia, Red Hat Network no podrá instalarla automáticamente en un sistema.
  4. El nombre del archivo del paquete RPM debe venir en el formato NVR (nombre, versión, lanzamiento) y debe contener la arquitectura para el paquete. El formato apropiado es nombre-versión-lanzamiento.arquitectura.rpm. Por ejemplo, un nombre de archivo de paquete RPM válido es pkgname-0.84-1.i386.rpm, en donde: nombre es pkgname, versión es 0.84, lanzamiento es 1, y arquitectura es i386.
  5. El paquete RPM debe ser firmado por la persona encargada de mantener el paquete. Los paquetes sin firma pueden ser distribuidos a través de Red Hat Network, pero el actualizador yum debe ser forzado a aceptarlos. La firma de paquetes es muy recomendable y se discute en la Sección 3.2, “Firma digital para los paquetes de RHN”.
  6. Si el paquete cambia de alguna manera, incluyendo cambios en la firma o recopilación, la versión o lanzamiento deben incrementarse. En otras palabras, el NVRA (incluyendo la arquitectura) para cada RPM distribuido a través de RHN debe corresponder con una única construcción para evitar ambigüedades.
  7. Ningún paquete RPM puede ser obsoleto a sí mismo.
  8. Si un paquete es dividido en paquetes separados, tenga mucho cuidado con las dependencias. No divida un paquete a menos de que haya una buena razón para hacerlo.
  9. Ningún paquete debe depender de scripts interactivos de pre-instalación, post-instalación, pre-desinstalación, o post-desinstalación. Si el paquete requiere intervención directa del usuario durante la instalación, no funcionará con Red Hat Network.
  10. Ningún script de pre-instalación, post-instalación, pre-desinstalación, o post-desinstalación debe escribir en stderr o stdout. Redirija los mensajes a /dev/null en caso de ser necesario. De otro modo, envíelos a un archivo.
  11. Al crear el archivo spec, utilice las definiciones de grupo de /usr/share/doc/rpm-<versión>/GRUPOS. Si no hay una coincidencia exacta, seleccione la más cercana.
  12. Utilice la función de dependencias de RPM para asegurarse de que el programa funcione después de ser instalado.

Importante

No cree un RPM archivando ficheros y luego desarchivándolos en el script de post-instalación. Esto va en contra del propósito de RPM.
Si los ficheros en el archivo están incluidos en la lista, éstos no pueden ser verificados o examinados en busca de conflictos. En la gran mayoría de casos, RPM mismo puede empacar y desempacar archivos de una forma más apropiada. Por ejemplo, no cree los archivos en un %post que no se limpien en la sección %postun.