Cómo empaquetar software con RPM, Parte 1: Elaboración y distribución de paquetes

En éste, el primer artículo de una serie de tres partes sobre RPM Package Manager, usted aprenderá a usar RPM no solo para instalar software y archivos relacionados, sino para armar paquetes con prácticamente todo, desde scripts de sistemas hasta códigos fuente o documentación. (Esta serie reemplaza a una anterior sobre RPM escrita por Dan Poirier.)

Comparta su experiencia: ¿Cuáles son sus trucos favoritos de RPM? 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

El principal beneficio del software de código abierto es, como su nombre lo indica, el acceso al funcionamiento interno de una aplicación. Contando con la fuente, usted puede estudiar cómo funciona una aplicación; cambiar, mejorar y extender su operación; tomar y redireccionar el código (según los límites de la licencia de la aplicación); y trasladar la aplicación a plataformas novedosas y emergentes.

Sin embargo, este libre acceso no siempre es deseable. Por ejemplo, quizás un usuario no desee tener la responsabilidad de construir a partir de un código fuente, sino que simplemente desea instalar el software como si fuera una aplicación en un paquete cerrado: insertar los medios, ejecutar la configuración, responder a algunos prompts, y terminar. De hecho, la mayoría de los usuarios de sistemas prefiere este tipo de software pre-elaborado. Los códigos pre-elaborados son menos sensibles a los caprichos de los sistemas y por lo tanto son más uniformes y predecibles.

Por lo general, la aplicación de código abierto pre-elaborada se denominapaquetey encierra todos los archivos binarios, de datos y de configuración que se requieren para ejecutar la aplicación. Además, un paquete incluye todos los pasos necesarios para implantar la aplicación en un sistema, generalmente en forma de scripts. El script puede generar datos, iniciar o detener servicios del sistema, o manipular archivos y directorios. Un script puede, también realizar operaciones para actualizar el software existente a una nueva versión.

Debido a que cada sistema operativo tiene su propia idiosincrasia, los paquetes se adaptan normalmente a los distintos sistemas específicos. Más aún, cada sistema operativo ofrece su propio administrador de paquetes, que es un utilitario especial que sirve para agregar y quitar paquetes en el sistema. Por ejemplo, los sistemas basados en Debian Linux® - usan la herramienta Advanced Package Tool (APT), mientras que los sistemas Fedora Linux usan el RPM Package Manager. El administrador de paquetes elimina las instalaciones parciales o con fallas y los aplicativos de desinstalación mediante el agregado o la eliminación de automáticos archivos en un paquete. El administrador de archivos también lleva un registro de todos los paquetes instalados en el sistema y puede validar con anterioridad la existencia de requisitos previos o conjuntos.

Si usted es un desarrollador de software o un administrador de sistemas, observará que las aplicaciones provistas como paquetes facilitan en gran medida las instalaciones, las actualizaciones y el mantenimiento. Aquí, usted aprenderá a usar el famoso RPM Package Manager para empaquetar una utilidad. Para demostrarlo, usted empaquetará la utilidad de conexión en red wget, que descarga archivos de Internet. La utilidad wget es útil aunque no siempre es estándar en las distribuciones. (Generalmente las distribuciones incluyen una utilidad analógica, curl.) Tenga presente que usted puede usar RPM para distribuir casi todos los — scripts, la documentación y los datos, y para — realizar casi todas las tareas de mantenimiento.

Construcción manual de wget y

La utilidad wget, al igual que muchas otras aplicaciones de código abierto, se puede construir de manera manual. La comprensión del proceso constituye el punto de inicio para el armado de un paquete de wget. Según la convención generalizada, la construcción de wget requiere el seguimiento de cuatro pasos:

  1. Descarga y apertura de la fuente.
  2. Configuración de la construcción.
  3. Elaboración del código.
  4. Instalación del software.

Usted puede descargar la última versión del código fuente de wget en ftp.gnu.org (ver Recursos para ingresar al vínculo, desde el mes de septiembre de 2009, la versión actual de wget era 1.12). El resto de los pasos requieren la línea de comandos, como se muestra en el Listado 1.

Listado 1. Instalación de wget
$ 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

./configureconsulta al sistema y establece las opciones de compilación que se adecuan al hardware y al software detectados. make compila el código, ysudo make installinstala el código en los directorios del sistema. De manera predeterminada, los directorios tiene su root en /usr/local, si bien usted puede, con la opción --prefix= /some/full/path/name, cambiar el root objetivo a./configure.

Para convertir este proceso a RPM, usted coloca la fuente en un repositorio y escribe un archivo de configuración que indique dónde encontrar la fuente que se debe compilar y cómo construir e instalar el código. El archivo de configuración, denominadospec file,constituye los datos de entrada a una utilidad denominada rpmbuild. El archivo spec y los binarios son empaquetados por rpmbuilden un RPM. Cuando otros usuarios descargan su RPM, la utilidad rpm lee el archivo spec e instala el paquete según sus instrucciones previamente escritas.


Construcción de su primer RPM

Antes de continuar, le daré un consejo. En el pasado, los paquetes eran construidos por root, el superusuario, debido a que root era el único usuario capaz de acceder al repositorio de códigos fuente del sistema. Sin embargo, este enfoque resultaba potencialmente riesgoso. Debido a que root puede alterar cualquier archivo del sistema, era fácil alterar sin darse cuenta un sistema en ejecución con el agregado de archivos extraños o la remoción de archivos importantes durante las construcciones interinas de un RPM. Más recientemente, el sistema RPM cambió para permitir a cualquier usuario la construcción de RPMs en un directorio local. Construir un RPM sin los privilegios de root evita que se produzcan cambios en los archivos del sistema central. A continuación se muestra el enfoque moderno.

Para construir un RPM, usted deberá:

  • Establecer una jerarquía de directorios según las especificaciones rpmbuild.
  • Colocar su código fuente y los archivos suplementarios en las ubicaciones adecuadas dentro de la jerarquía.
  • Crear su archivo spec.
  • Construir el RPM. Opcionalmente, usted puede construir un RPM de origen paa compartir su código fuente con los demás.

Para comenzar, construya la jerarquía. En un directorio de su directorio local, — digamos, $HOME/mywget — cree cinco subdirectorios:

  • BUILD. BUILD se usa como un espacio de scratch para realmente compilar el software.
  • RPMS. RPMS contiene el RPM binario que construye rpmbuild.
  • SOURCES. SOURCES es para el código fuente.
  • SPECS. SPECS contiene su/s archivo/s spec — un archivo spec por cada RPM que desee construir.
  • SRPMS. SRPMS contiene el RPM de origen construido durante el proceso.

Como mínimo, usted necesita código fuente en SOURCES y un archivo spec en SPECS.

Copie la fuente, que idealmente estará empaquetada como un tarball, al directorio SOURCES, como se muestra en el Listado 2. De ser necesario, dé un Nuevo nombre al tarball para incluir el número de versión de la aplicación con el fin de diferenciarla de las demás. La principal convención es package-version.tar.gz. En el caso de wget, usted deberá usar:

Listado 2. Copiado de Source
$ 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 continuación, cree el archivo spec. Un archivo spec es nada más que un archivo de texto con una sintaxis particular. El Listado 3 muestra un ejemplo de archivo spec.

Listado 3. Muestra de archivo spec
# 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

Revisemos el archivo spec de arriba a abajo. Las líneas 1-5 definen un conjunto de variables de conveniencia que se usan en todo el resto del archivo. Las líneas 7-15 establecen un número de parámetros necesarios usando la formaparameter: value. Como usted puede ver en la línea 7 y las demás ubicaciones, las variables pueden ser evaluadas y combinadas para generar el valor de una configuración.

Los nombres de los parámetros son en gran medida evidentes por sí mismos, pero BuildRoot amerita cierta explicación para diferenciarlo del directorio BUILD que usted ya ha creado. BuildRoot es un proxy para el directorio de instalación final. En otras palabras, si wget se instala en útima instancia en /usr/local/bin/wget y otros sub-directorios en /usr/local, como por ejemplo /usr/local/man para la documentación, BuildRoot sustituye a /usr/local durante el proceso de construcción de RPM. Una vez que usted fije BuildRoot, podrá acceder a su valor con la variable de entorno RPM_BUILD_ROOT. Siempre deberá fijar BuildRoot en su archivo spec y controlar los contenidos de ese directorio para verificar qué es lo que el paquete va a instalar.

A continuación ofrecemos algunos consejos prácticos:

  • No use ./configure --prefix=$RPM_BUILD_ROOT. Este comando construye todo el paquete, suponiendo que la ubicación final de los archivos es el root de la construcción. Es probable que esto haga fallar a cualquier programa que deba localizar sus archivos instalados en tiempo de ejecución, debido a que cuando su RPM se encuentre finalmente instalado en el sistema de un usuario, los archivos ya no estarán bajo el root de la construcción — que es simplemente un directorio temporal en el sistema de su construcción.
  • No incluya una ruta en la definición de la Fuente.
  • La versión y la edición son particularmente importantes. Cada vez que usted cambie el código o los datos de su aplicación y ponga a disposición un nuevo RPM, asegúrese de aumentar los valores de la Versión y la Edición para reflejar los cambios importantes y menores realizados respectivamente. Quizás le resulte útil incrementar el número de edición cada vez que usted construye un RPM, incluso para su uso propio, a fin de mantener los intentos por separado.

La siguiente sección comienza con %description. Aquí, usted deberá brindar una descripción clara pero concisa del software. Esta línea se muestra cada vez que un usuario ejecuta rpm -qi para consultar la base de datos del RPM. Usted puede explicar qué hace el paquete, describir cualquier aviso o instrucción de configuración adicional, etc.

A continuación aparecen consecutivamente las secciones %prep, %build, y %install. Cada una de ellas genera un shell script que está incrustado en el RPM y todas se ejecutan en forma consecutiva como parte de la instalación. %prep déjà listo el código fuente, por ejemplo abriendo el tarball. Aquí, %setup -q es un macro de %prep que sirve para abrir automáticamente el tarball nombrado en Source.

Las instrucciones de la sección %build le deberán parecer familiares. Son idénticas a los pasos que usted siguió para configurar y poner en funcionamiento manualmente la construcción. La sección %install también es identica. Sin embargo, mientras el objetivo de la construcción manual era el verdadero directorio /usr/local de su sistema, el objetivo de la instrucción %install es ~/mywget/BUILD.

%files enumera los archivos que se deberán agrupar en el RPM y, como opción, establece permisos y otro tipo de información. Dentro de %files, usted puede usar el macro %defattr para definir los permisos predeterminados, el propietario y el grupo de archivos del RPM; en este ejemplo, %defattr(-,root,root) instala todos los archivos propiedad de root, usando cualquier permiso encontrado cuando el RPM los agrupó desde el sistema de la construcción.

Usted puede incluir múltiples archivos por línea en %files. Usted puede etiquetar los archivos agregando %doc o %config a la línea. %doc le dice al RPM que el archivo es un archivo de documentación, de manera que si un usuario instala el paquete usando --excludedocs, el paquete no se instalará. %config le dice al RPM que éste es un archivo de configuración. Durante las actualizaciones, el RPM intentará evitar la sobreescritura en la configuración cuidadosamente modificada por un usuario con un archivo de configuración predeterminado del paquete del RPM.

Tenga presente que si usted enumera un nombre de directorio bajo %files, el RPM incluirá todos los archivos en ese directorio.


Cómo acelerar el RPM

Ahora que sus archivos están ubicados y su archivo spec está definido, usted está listo para construir el archivo RPM verdadero. para hacerlo, use la utilidad correctamente denominada rpmbuild:

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

Este comando usa el archivo spec nombrado para construir un paquete (-bb para "build binary") con detallados datos de salida (-v). La utilidad de la construcción remueve el árbol de la construcción luego de elaborar los paquetes (--clean). Si además usted deseaba construir el RPM de origen, especifique -ba ("build all") en lugar de -bb. (Consulte la página man rpmbuild para ver un listado complete de opciones.)

rpmbuild lleva a cabo estos pasos:

  • Lee y analiza el archivo wget.spec.
  • Ejecuta la sección%preppara abrir el código fuente en un directorio temporal. En este caso, el directorio temporal es BUILD.
  • Ejecuta la sección%buildpara compilar el código.
  • Ejecuta la sección%installpara instalar el código en directorios de la máquina de construcción.
  • Lee la lista de archivos de la sección%files, los reúne, y crea un RPM binario (y los archivos del RPM de origen, si usted lo eligiera).

Si usted examina su directorio $HOME/mywget, deberá encontrar un nuevo directorio denominado wget-1.12-root. Este directorio es un proxy para el destino objetivo. Además, deberá encontrar un nuevo directorio denominado RPMS/i386, que a su vez contendrá su RPM, denominado wget-1.12-1.i386.rpm. El nombre del RPM refleja que se trata de la versión 1.12 wget para el procesador i386.

Para comprobar si el RPM contiene los archivos adecuados, usted puede usar el comando rpm, como se muestra en el Listado 4.

Listado 4. Verificación de los contenidos del RPM
$ 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 . . .

El comandorpm -Vp RPMS/i386/wget-1.12-1.i386.rpm controla el paquete en relación con los archivos del sistema. Si bien al parecer existe una gran cantidad de errores, cada uno de ellos indica que los contenidos del archivo RPM son correctos. Si usted está esperando que se instale un archivo y el mismo no aparece en los datos de salida, significa que no fue incluido en el paquete. En ese caso, revise el archivo spec y asegúrese de que el archivo esté enumerado en la sección %files.

Luego de verificar el RPM, usted puede distribuir el archivo a sus compañeros de trabajo. Una vez que sus colegas reciban el archivo, deberán ejecutar rpm para instalar wget en sus propios sistemas:

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

Otros usos del RPM

Esta breve introducción apenas toca la superficie de lo que es posible hacer con el RPM. Si bien se lo usa con mayor frecuencia para instalar software y archivos relacionados, usted podrá empaquetar casi cualquier cosa, desde scripts de sistemas a códigos fuente o documentación. Y como podrá ver en la segunda entrega de esta serie, también podrá usar RPM para corregir errores en el código fuente además e volver a construir y reinstalar software. El formato de distribución de RPM se encuentra en numerosos sistemas Linux y es el método preferido de instalación para el software binario de los sistemas Red Hat y Fedora, entre otros.

Si usted construye y empaqueta con RPM, ellos vendrán.

Recursos

Aprender

Obtener los productos y tecnologías

  • Descargue la última versión del código fuente de wget en ftp.gnu.org.
  • Conozca más y descargue rpmlint.
  • Conozca más y descargue Easy RPM Builder.
  • Con el software de prueba de IBM , disponible para su descarga directamente en developerWorks, construya su próximo proyecto de desarrollo en Linux.

Comentar

  • Involúcrese en la comunidad My developerWorks. Conéctese con otros usuarios de developerWorks al tiempo que explora los blogs, foros, grupos y wikis de 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=468308
ArticleTitle=Cómo empaquetar software con RPM, Parte 1: Elaboración y distribución de paquetes
publish-date=01152010