En las primeras épocas de la computación, cada pieza de software era monolítica. Excepto la memoria ROM, que se utilizaba para arrancar una máquina, y el sistema operativo propiamente dicho, cada aplicación proporcionaba todas las bibliotecas y el código necesario para ejecutar el programa. Este enfoque era adecuado, en gran medida debido a que las computadoras de esa época no podían realizar tareas múltiples. No obstante, posteriormente, las computadoras avanzaron a pasos agigantados para dar soporte tanto a múltiples usuarios simultáneos (tiempo compartido) como a múltiples aplicaciones simultáneas. Al existir gran cantidad de usuarios que ejecutan la misma aplicación y comparten los recursos del sistema, por ejemplo la RAM y el sistema del archivo, compartir el código se convirtió en una necesidad y en una optimización.

En la actualidad, casi todos los sistemas operativos separan el código de la biblioteca del código de la aplicación y unen los dos en el momento de ejecutar. Sin embargo, una Biblioteca compartida — y un código que se puede compartir tienen — elementos a favor y en contra. Entre los elementos a favor, se puede decir que cada aplicación es más pequeña porque no es necesario que sea monolítica. Además, la reparación de un error o una mejora del rendimiento que se realiza en una biblioteca compartida de uso frecuente benefician a todas las aplicaciones. No obstante, separar el código de la aplicación del código de la biblioteca es una especie de callejón sin salida: la biblioteca compartida debe estar disponible y ser compatible, de lo contrario, la aplicación no se podrá ejecutar.

El vínculo entre una aplicación y una biblioteca es un tipo de dependencia. También se considera una dependencia cuando usted distribuye código fuente y necesita un equipo particular de archivos de encabezado para compilar el código. Es posible que su código también requiera una herramienta específica para compilar, por ejemplo Bison o Yacc. Si distribuye su software en un RPM, debe verificar que el sistema de destino suministre todas las dependencias antes de instalar su código. Después de todo, si un sistema no es apropiado, no hay motivos para instalar la aplicación.

En la Parte 1 de esta serie se demostró cómo distribuir su software por medio de RPM. En la Parte 2 se describieron en detalle los procesos de instalación y desinstalación y se explicó cómo instalar los componentes cuando se instala un paquete complementario en el futuro. En este artículo, que es el último de la serie, se analiza otro tema importante, que son las —dependencias del software — y se debaten las capacidades adicionales que sirven para controlar y personalizar su empaquetado de software.

Definición de las dependencias

Cuando crea un paquete RPM, puede declarar cuatro tipos de dependencias:

• Si su paquete requiere una capacidad que le proporciona otro, defina un requisito.
• Si otros paquetes dependen de una capacidad de su software, o podrían depender de esta, declare cuál es la capacidad que su paquete proporciona.
• Si su software (o parte de su software) no puede existir de manera simultánea con otro paquete, especifique un conflicto.
• Si su paquete rechaza otro paquete o una versión anterior de su propio software, defina la parte que se ha vuelto obsoleta. Si su paquete cambia de nombre, debe listar el nombre anterior como obsoleto.

Cada dependencia se lista por separado en el archivo de especificaciones de RPM. La sintaxis es Type: Capability donde Type (tipo) es una de las cuatro etiquetas epónimas (Requires, Provides, Conflicts, o Obsoletes) andCapability (Capacidad) es el nombre de un número opcional de versión. Si tiene más de una Capability para listar, enumere todas en la misma línea, delimitadas por un espacio o una coma.

Por ejemplo, si su aplicación requiere Perl para ejecutar, usted debe especificar lo siguiente:

Requires: perl

si su aplicación requiere Perl y MySQL, puede escribir:

Requires: perl, mysql

Con frecuencia una aplicación depende de una versión específica o de un lanzamiento específico importante de un paquete. Por ejemplo, si escribe un código Ruby que es compatible con la versión 1.9, dependerá de esa misma versión del intérprete. Para expresar la dependencia de una versión, agregue el número de versión a la Capability :

Requires: ruby >= 1.9

Puede especificar números de versión para cualquiera de los cuatro tipos de dependencias. La sintaxis es idéntica. Por ejemplo, si su aplicación era incompatible con las versiones de shell bash posteriores a la versión 2.0, deberá escribir:

Conflicts: bash > 2.0

Existen seis comparadores para el número de versión:

• package < revision requiere que el package nombrado tenga un número de versión menor que revision .
• package > revision especifica un package más nuevo que la revision .
• package >= revision pide un package mayor o igual que la revision .
• package <= revision requiere un package menor o igual que la revision .
• package = revision da instrucciones específicas de una revision .
• package pide una revisión del paquete nombrado package .

En general, la información para Requires y Provides se genera de manera automática sobre la base del análisis de RPM de su código y su archivo de especificaciones respectivamente. (Puede aproximar qué computa RPM para Requires utilizando ldd, utilidad ldd). No obstante, puede corregir esas dos listas, si es necesario.Conflicts and Obsoletes son, en general, suministrados por el desarrollador del software.

Volver arriba

Firma de su RPM

Muchos desarrolladores eligen RPM porque es fácil de usar y tiene un soporte extendido. Sin embargo, su misma simplicidad lo hace proclive a que un mal actor instale el RPM, modifique sus contenidos y vuelva a empaquetar y a distribuir el software como auténtico. Los sitios espejo y los torrentes sirven para acelerar estos actos de "piratería". Para protegerse y para proteger a los que eligen su software, registre su RPM con una firma única para garantizar su autenticidad. La firma impide que se hagan modificaciones: Cualquier cambio que se realice en el archivo altera la firma y revela una falsificación

Existen tres maneras de firmar su paquete. Puede hacerlo cuando ya esté generado. Puede volver a firmar un paquete que ya fue firmado. También puede firmar un RPM existente que no tiene firma. Las últimas dos opciones se generaron sobre la técnica de la primera, por lo tanto, es importante concentrarse en firmar un RPM cuando está generado.

Para comenzar, debe tener un par compuesto por clave pública-clave privada GPG. Si le falta alguna, es sencillo generarla. El primer paso es iniciar un gpg-agent, que gestiona claves secretas (En general, los sistemas ejecutan un gpg agent único para todos los usuarios. Verifique con el administrador de su sistema para determinar si este paso es necesario. Si los sistemas ya ejecutan el agente, pregunte cómo conectarse a ese agente).

$ gpg-agent --daemon --enable-ssh-support \ --write-env-file
                "${HOME}/.gpg-agent-info"

gpg-agent crea el archivo .gpg-agent-info en su directorio principal. El archivo contiene configuraciones del entorno shell que se requieren para conectarse al agente que se está ejecutando. Cargue la información con el siguiente comando. (Tipee el comando completo en el prompt o, para que le resulte más práctico, agréguelo a su archivo de inicio shell).

$ if [ -f "${HOME}/.gpg-agent-info" ]; then .
                "${HOME}/.gpg-agent-info" export GPG_AGENT_INFO export SSH_AUTH_SOCK export
                SSH_AGENT_PID fi

Finalmente, configure una variable adicional para indicar el dispositivo de la terminal que está usando. (Nuevamente usted puede agregar estas dos líneas a un archivo de inicio shell para que esté disponible para cada sesión interactiva).

$ GPG_TTY=$(tty) $ export GPG_TTY

Ahora está listo para generar una clave. Ejecute el comando gpg --gen-key y responda los prompts. Se muestra como ejemplo, una sesión de generación de clave en el Listado 1. La entrada de datos se muestra en negrita.

$ gpg --gen-key gpg (GnuPG) 1.4.9;
                Copyright (C) 2008 Free Software Foundation, Inc. This is free software: you are
                free to change and redistribute it. There is NO WARRANTY, to the extent permitted by
                law. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA
                (sign only) (5) RSA (sign only) Your selection? 1 DSA keypair will have 1024
                bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want?
                    (2048) 1024 Requested keysize is 1024 bits Please specify how long the key
                should be valid. 0 = key does not expire <n> = key expires in n days
                <n>w = key expires in n weeks <n>m = key expires in n
                months <n>y = key expires in n years Key is valid for? (0) 0 Key
                does not expire at all Is this correct? (y/N) y Necesita tener una ID de
                usuario para identificar su clave; el software construye la ID de usuario a partir
                del Real Name (Nombre real), el Comment (Comentario) y la Email Address (Dirección
                de correo electrónico) en el siguiente formulario: "Heinrich Heine (Der Dichter)
                <heinrichh@duesseldorf.de>" Real name: Martin Streicher Email
                    address: martin.streicher@example.com Comment: Example key for RPM You
                selected this USER-ID: "Martin Streicher (Example key for RPM)
                <martin.streicher@example.com>" Change (N)ame, (C)omment, (E)mail or
                    (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. Enter
                    passphrase: ****** Retype passphrase: ****** We need to generate a lot
                of random bytes. It is a good idea to perform some other action (type on the
                keyboard, move the mouse, utilize the disks) during the prime generation; this gives
                the random number generator a better chance to gain enough entropy.
                +++++++++++++++++++.+++++.++++++++++++++++++++.+++++>.+++++.+++++..>+++++.+++++

El primer prompt elige el tipo de clave (la opción preferida es la predeterminada). El prompt siguiente configura el tamaño de la clave en bits. En este caso, es mejor que haya la mayor cantidad posible de bits, aunque las claves más largas tardan tiempo adicional en generarse. Si lo desea, puede configurar una fecha de caducidad de la clave en el próximo prompt. Las tres consultas siguientes piden información para identificar esta clave. En general, se suministra su nombre y su dirección de correo electrónico para que los usuarios lo puedan contactar para su clave pública. Finalmente, se le dan dos avisos para que ingrese una contraseña para agregar un nivel adicional de seguridad. Nadie podrá firmar un RPM con su clave sin la contraseña correspondiente. La generación de clave puede tardar segundos o minutos. Esto dependerá de si su sistema está ocupado.

Al finalizar, el generador de claves crea un nuevo directorio denominado $HOME/.gnupg y lo llena de archivos que representan sus claves privadas y públicas. Para ver las claves que tiene disponibles, ejecute gpg --list-key Tome nota del valor de uid: Contiene el nombre de la clave que debe usar para firmar su RPM.

$ gpg
                --list-key /home/strike/.gnupg/pubring.gpg-------------------------------pub
                1024D/1811A3E4 2009-11-23 uid Martin Streicher (Example key for RPM)
                <martin.streicher@example.com> sub 1024g/15BBCF06 2009-11-23

Para continuar, debe configurar opciones para RPM para firmar el paquete. Cree o abra el archivo $HOME/.rpmmacros y agregue tres líneas:

%_signature gpg %_gpg_path /home/strike/.gnupg %_gpg_name Martin
                Streicher (Example key for RPM) <martin.streicher@example.com>

La línea %_signature selecciona el tipo de firma. Aquí se configura para gpg El %_gpg_name especifica la ID de la clave con la que se va a firmar. Durante la generación de clave, el nombre se configuró para Martin Streicher (Example key for RPM) <martin.streicher@example.com> (el valor de la ID de usuario [UID] mencionada), para que se repita aquí. Finalmente, %_gpg_path define la ruta de acceso a sus claves.

Una vez que las claves y la configuración estén en su lugar, firmar un RPM requiere una opción adicional, --sign.

$ rpmbuild -v --sign -bb --clean SPECS/wget.spec Enter pass phrase:
                Pass phrase is good. Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.46786 + umask 022
                ...

El comando rpmbuild que se muestra es el mismo que se utiliza en la Parte 1. — Sólo se agrega --sign Cuando se le solicite su contraseña, ingrese la misma contraseña que registró durante la generación de clave. La construcción de RPM continúa y firma el paquete resultante.

Puede verificar su firma para asegurarse de que su paquete es legítimo. Para verificar la firma de un RPM, ejecute rpm -K en el mismo archivo:

$ rpm -K wget-1.12-1.i386.rpm wget-1.12-1.i386.rpm: (SHA1) DSA sha1
                md5 (GPG) OK

Si el comando dice OK significa que el archivo es legítimo. Si descarga el RPM de otro desarrollador, verifíquelo antes de instalar el paquete.

Volver arriba

Herramientas adicionales para el desarrollo RPM

Si suele utilizar RPM para el empaquetado, los archivos de especificaciones están naturalmente. No obstante, existe una amplia variedad de herramientas disponibles para facilitar la autoría de los archivos de especificaciones. Aquí hay una muestra (ver Recursos para acceder a cada vínculo específico):

• rpmlint valida los archivos RPM. La herramienta capta una buena cantidad de errores — La instalación de un binario en /etc y un archivo de configuración en /usr son dos dificultades comunes que rpmlint puede detectar — y usted puede extender esto con módulos personalizados. rpmlint está escrito en Python y requiere una cantidad de bibliotecas para cumplir con sus funciones.
• Easy RPM Builder es una herramienta basada en K Desktop Environment (KDE) / Entorno de Escritorio K (KDE) para ensamblar paquetes. La herramienta proporciona una cantidad de plantillas para ayudar al arranque de su desarrollo RPM y suministra una interfaz gráfica de usuario (GUI) a porciones del archivo de especificaciones. Easy RPM Builder no reemplaza rpmbuild y se requiere tener algunos conocimientos de RPM para usarlo con buenos resultados.
• Si no utiliza KDE o prefiere trabajar con el archivo de especificaciones directamente, puede extender tanto Vim como Emacs para incluir un modo especial de especificaciones, que resalta la sintaxis del archivo de especificaciones y dirige la creación y el mantenimiento de un archivo de especificaciones.
• Si bien no se trata de una herramienta propiamente dicha, la página de Pautas para RPM (RPM Guidelines) del Proyecto Fedora proporciona una vasta lista de mejores prácticas. En realidad, si intenta distribuir su software en Fedora, preste especial atención a los requisitos para los paquetes nuevos. Además, las pautas describen cómo empaquetar las aplicaciones basadas en una cantidad de plataformas populares, incluyendo Eclipse, Perl y Ruby. El empaquetado de software para un intérprete en particular es especialmente complicado porque el software empaquetado puede incluir scripts, binarios y fuente que se deben volver a generar directamente durante la instalación en la máquina de destino. Por ejemplo, un módulo Perl puede ser en parte Perl y en parte código C También puede hallar una versión de la guía oficial de software de RPM en el sitio de Fedora (ver Recursos a continuación para obtener un vínculo).

Existen herramientas adicionales que ayudan a instalar y administrar los RPM. En general, estas herramientas se crean para administradores de sistemas pero le pueden resultar de utilidad para ayudarlo a validar sus instalaciones y a administrar el software de su propio sistema de desarrollo. Si utiliza su propio sistema de desarrollo para pruebas, es posible que estas herramientas le sean útiles para purgar paquetes caducos.

Volver arriba

Conclusión

RPM recibe mantenimiento activo. Puede hacer un seguimiento de los esfuerzos realizados en la nueva página principal del proyecto (ver Recursos) Existen herramientas de RPM para la mayoría de las distribuciones de Linux, incluyendo Debian. La última versión de RPM es 5.2.0, que se lanzó en julio de 2009. Las metas del proyecto RPM siguen siendo las mismas: "Facilitar la colocación y remoción de paquetes del sistema. Facilitar la verificación de que un paquete se instaló correctamente. Facilitar el trabajo del generador del paquete. Lograr que se inicie con el código fuente original. Hacer que trabaje en diferentes arquitecturas de computadoras".

El desarrollo RPM puede ser complejo porque instalar software es igualmente complejo. En esta serie se mencionaron algunos temas. Puede encontrar gran cantidad de información sobre el desarrollo RPM en Internet. Existen tutoriales, foros y hasta un canal de IRC dedicado al tema (visite #rpm.org en Freenode). Además, hay cientos, y hasta miles, de otros RPM online. Si surge algún problema particularmente complicado, encuentre otro paquete RPM con similitudes y realice el sondeo de su archivo de especificaciones para hallar una solución.

Si usted es desarrollador de software o administrador de un sistema, proporcionar su aplicación como paquete facilita las instalaciones, las actualizaciones y el mantenimiento. Si lo construye y empaqueta con RPM, su adopción será generalizada.

Recursos

Aprender

• Lea los tres artículos de esta serie(developerWorks, enero de 2010) en RPM Package Manager.
  
  
• Lea los comentarios de Wikipedia's sobre el RPM Package Manager..
  
  
• Visite el sitio oficial de RPM para obtener más información sobre la gestión de paquetes en Linux.
  
  
• Infórmese sobre RPMin Red Hat Linux.
  
  
• Lea las Pautas para RPM del Proyecto Fedora.
  
  
• Obtenga la Guía oficial de software de RPMde Fedora.
  
  
• Lea todos los artículos de Martin en developerWorks
  
  
• En el área de developerWorks Linux, encuentre más recursos para desarrolladores de Linux y haga un escaneo de nuestros artículos y tutoriales más populares.
  
  
• Vea todos los consejos de Linux y tutoriales de Linux en developerWorks.
  
  
• Esté actualizado con los eventos técnicos y las transmisiones por Internet de developerWorks.
  
  

Obtener los productos y tecnologías

• Aprenda más y descargue rpmlint .
  
  
• Aprenda más y descargue Easy RPM Builder.
  
  
• Con el software de prueba IBM, que se encuentra disponible para descargar directamente desde developerWorks, construya su próximo proyecto de desarrollo en Linux.
  
  

Comentar

• Involúcrese en la comunidad de My developerWorks Conéctese con otros usuarios de developerWorks mientras explora los blogs, los foros, los grupos y los wikis dirigidos por desarrolladores.
  
  

Sobre el autor

Martin 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..

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Definición de las dependencias
• Firma de su RPM
• Herramientas adicionales para el desarrollo RPM
• Conclusión
• Recursos
• Sobre el autor
• Comentarios