RPM Como 6

RPM COMO : Construyendo paquetes RPM Anterior Siguiente Indice

6. Construyendo paquetes RPM

Construir paquetes RPM es algo realmente fácil de hacer, especialmente si puede conseguir que el software que intenta empaquetar pueda compilarse por sí mismo.

El procedimiento básico es el siguiente:

Asegúrese que su /etc/rpmrc está configurado para su sistema.
Hágase con el código fuente del software a empaquetar para ser compilado en su sistema.
Haga un parche con todos los cambios que ha tenido que realizar para que los fuentes se compilen adecuadamente.
Cree un fichero .spec para el paquete.
Asegúrese de que todo está en su sitio.
Construya el paquete usando RPM.

En general, RPM construirá tanto el paquete binario como el de los fuentes.

6.1 El fichero `rpmrc`

En lo sucesivo, la única configuración de RPM está disponible en el fichero /etc/rpmrc. Éste puede tener la siguiente apariencia:


require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager:  Mickeysoft Packaging Account <packages@mickiesoft.com>

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2

signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp

tmppath: /usr/tmp

La línea require_vendor obliga a RPM a requerir una línea de vendor (distribuidor). Ésta puede venir o bien del propio fichero /etc/rpmrc o de la cabecera del fichero .spec. Para desactivar este parámetro debe cambiarse el número a 0. Esto también se aplica a las líneas require_distribution y require_group.

La siguiente línea es la de distribution N.T.: distribución . Puede definirla bien aquí o bien en el fichero .spec. Cuando se empaqueta para una distribución en concreto, es buena idea asegurarse de que esta línea es correcta, incluso cuando no se requiera. La línea de vendor N.T.: distribuidor funciona de la misma manera, aunque puede contener cualquier cosa (ej.: Joe's Software and Rock Music Emporium).

RPM también soporta ahora el empaquetado de paquetes para múltiples arquitecturas. El fichero rpmrc puede incluir una variable de opciones (optflags) que contiene parámetros específicos a la arquitectura. Lea secciones posteriores para saber cómo usar esta variable.

En adición a las macros anteriores, hay disponibles unas cuantas más. Puede usar:


rpm --showrc

para saber cuál de sus etiquetas están configuradas y cuáles son los parámetros disponibles.

6.2 El fichero `spec`

Ahora hablaremos del fichero .spec. Estos ficheros son imprescindibles para construir un paquete. El fichero spec es una descripción del software acompañado con instrucciones sobre cómo construirlo y una lista de ficheros de todos los binarios instalados.

Debería nombrar a sus ficheros spec de acuerdo a una convención estándar. Tal como nombre de paquete-guión-número de versión-guión-número de publicación-punto-spec.

A continuación, un pequeño fichero spec (eject-1.4.spec):


Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog

/usr/bin/eject
/usr/man/man1/eject.1

6.3 La Cabecera

La cabecera tiene unos cuantos campos estándar que usted necesita rellenar. También hay unas cuantas advertencias. Los campos deben ser rellenados tal como sigue:

Summary: Descripción en una sóla línea del paquete.
Name: La cadena que vaya a servir de nombre para el fichero rpm.
Version: La cadena que vaya a ser el número de versión para el fichero rpm.
Release: El número de publicación para un paquete dentro de un mismo número de versión (ej.: si crea un paquete y lo encuentra ligeramente defectuoso y necesita generarlo de nuevo, el siguiente paquete debería tener 2 como número de publicación).
Icon: El nombre del icono que podrán usar interfaces de instalación alto nivel (como Red Hat `glint''). Debe ser un fichero .gif y estar situado en el directorio SOURCES.
Source: Esta línea apunta a la localización HOME del fichero de fuentes original. Se usa si alguna vez quiere tener los fuentes de nuevo o chequear para nuevas versiones. Precaución: el nombre del fichero en esta línea DEBE coincidir con el nombre que tiene tal fichero en su sistema (ej.: no se haga con el fichero fuente y le cambie el nombre). Puede especificar más de un fichero fuente de esta forma:
Source0: blah-0.tar.gz Source1: blah-1.tar.gz Source2: fooblah.tar.gz
Estos ficheros deben residir en el directorio SOURCES. (La estructura de directorios es discutida en una sección posterior, ``El Árbol de Directorios de las Fuentes'', arbol).
Patch: El lugar donde podrán encontrarse los parches si los necesita de nuevo. Precaución: el nombre debe coincidir con el de SUS propios parches. Puede especificar más de un fichero de parches de esta forma:
Patch0: blah-0.patch Patch1: blah-1.patch Patch2: fooblah.patch
Estos ficheros deben residir en el directorio SOURCES.
Copyright: Hace referencia al modelo de copyright al que se acoje el paquete. Puede tratarse de algo al estilo de GPL, BSD, MIT, public domain N.T.: dominio público , distributable N.T.: distribuible o commercial N.T.: comercial .
BuildRoot: Hace referencia a un directorio que simulará el raíz (/) para la construcción e instalación de un nuevo paquete. Puede usarlo para probar su paquete antes de instalarlo en su máquina.

Group: Informa a un programa de instalación de alto nivel (como Red Hat `glint'') dónde situar este paquete en particular dentro de la jerarquía de rpm. Actualmente, esta jerarquía viene a ser:


Applications            (aplicaciones)
    Communications      (comunicaciones)
    Editors             (editores)
        Emacs           (Emacs)
    Engineering         (ingenieria)
    Spreadsheets        (hojas de calculo)
    Databases           (bases de datos)
    Graphics            (graficos)
    Networking          (redes de comunicaciones)
    Mail                (correo smtp)
    Math                (matematicas)
    News                (noticias nntp)
    Publishing          (edicion)
        TeX             (TeX)
Base                    (basico)
    Kernel              (nucleo)
Utilities               (utilidades)
    Archiving           (archivo)
    Console             (consola)
    File                (ficheros)
    System              (sistema)
    Terminal            (terminales)
    Text                (texto)
Daemons                 (demonios)
Documentation           (documentacion)
X11                     (X11)
    XFree86             (XFree86)
        Servers         (servidores)
    Applications        (aplicaciones)
        Graphics        (graficos)
        Networking      (redes de comunicaciones)
    Games               (juegos)
        Strategy        (estrategia)
        Video           (video juegos)
    Amusements          (entretenimientos)
    Utilities           (utilidades)
    Libraries           (librerias)
    Window Managers     (gestores de ventana)
Libraries               (librerias)
Networking              (redes de comunicaciones)
    Admin               (administracion)
    Daemons             (demonios)
    News                (noticias nntp)
    Utilities           (utilidades)
Development             (desarrollo)
    Debuggers           (depuradores)
    Libraries           (librerias)
        Libc            (libreria C)
    Languages           (lenguajes)
        Fortran         (fortran)
        Tcl             (tcl)
    Building            (Compilacion)
    Version Control     (control de versiones)
    Tools               (utiles)
Shells                  (interpretes de comandos)
Games                   (juegos)

%description En realidad no es un elemento de la cabecera, pero debe ser descrito junto a sus otras partes. Necesita una etiqueta de descripción por cada paquete o subpaquete. Se trata de un campo multilínea que debe ser usado para proporcionar una descripción comprensible del paquete.

6.4 `%prep`

Esta es la segunda sección del fichero spec. Se usa para tener las fuentas listas para compilar. Aquí necesita hacer todo lo necesario para obtener los fuentes parcheadas y configuradas para ejecutar un make con ellas.

Una cosa a señalar: Cada una de estas secciones es sólo un lugar para ejecutar guiones de intérprete de comandos N.T.: shell scripts en el original. . Así podrá crear un script simple para sh y colocarlo tras la etiqueta %prep para desempaquetar y parchear sus fuentes. En cualquier caso, hemos creado unas macros para ayudar en esto.

La primera de estas macros es %setup. En su forma más simple (sin parámetros en la línea de comandos), se limita a desempaquetar los fuentes y cambiar el directorio actual al de los fuentes. Puede tener alguna de las siguientes opciones:

-n nombre asignará el nombre del directorio en construcción. Por defecto es $NAME-$VERSIÓN. Otras posibilidades incluyen $NAME, ${NAME}${VERSIÓN}, o cualquiera que use el fichero tar principal. (Apercíbese de que estas variables ``$'' no son variables reales dentro del fichero spec. Sólo se usan aquí en lugar de un nombre ejemplo. Necesitará usar el nombre real y la versión de su paquete, no una variable).
-c creará y cambiará al directorio nombrado antes de desempaquetar con tar.
-b # desempaquetará con tar el fichero fuente # antes de cambiar al directorio (y esto no tiene sentido con -c, así que no lo haga). Sólo es útil cuando se usan varios archivos fuente.
-a # desempaquetará el fichero fuente # después de cambiar al directorio.
-T Este parámetro anula la acción por defecto de desempaquetar el fichero fuente y requiere
-b 0 o -a 0 para desempaquetar el fichero fuente principal. Necesitará esto cuando hayan fuentes secundarias.
-D No borra el directorio antes de desempaquetar. Sólo resulta útil cuando tenga más de una macro de configuración. Debería ser usado solamente en macros de configuración después de la primera (pero nunca en la primera).

La siguiente de las macros disponibles es %patch. Esta macro ayuda a automatizar el proceso de aplicación de parches a los fuentes. Necesita de varios parámetros, listadas a continuación:

# aplicará el parche Patch#.
-p # especifica el número de directorios a evitar por el comando patch(1).
-P La acción por defecto es aplicar Patch (o Patch0). Este parámetro inhibe dicha acción y requiere un 0 para tener desempaquetado el fichero fuente principal. Esta opción resulta útil en una segunda (o posterior) macro %patch que requiera parámetros distintos a la primera macro.
También puede hacer %patch# en lugar de hacer el comando real: %patch # -P

Estas deberían ser todas las macros que necesite. En cuanto las tenga claras, podrá crear cualquier otra configuración que necesite mediante guiones sh. Todo lo que incluya hasta la macro %build (discutida en la siguiente sección) es ejecutado vía sh. Busque en el ejemplo anterior el tipo de cosas que puede querer incluir allí.

6.5 `%build`

En realidad no hay ninguna macro en esta sección. Solamente debe incluir todos los comandos que necesitaría para construir y/o compilar el software una vez que haya desempaquetado y parcheado los fuentes, y se haya movido al directorio correcto. Es pues otra serie de comandos pasados a sh, así que cualquier comando aceptable por sh podrá ir aquí (incluidos los comentarios). El directorio actual es reajustado en cada una de estas secciones al de mayor nivel en el directorio de fuentes, así que téngalo en cuenta. Puede moverse a través de los subdirectorios si resultase necesario.

6.6 `%install`

En realidad no hay ninguna macro en esta sección. Básicamente debe incluir aquí cualquier comando necesario para instalar. Si el paquete a construir tiene disponible un comando make install, inclúyalo aquí. Si no, o bien puede parchear el fichero Makefile y añadirle la funcionalidad make install e incluir dicha sentencia en esta sección o bien instalarlo a mano mediante comandos sh. Puede considerar su directorio actual como el directorio superior del directorio de fuentes.

6.7 Guiones opcionales pre y post Install/Uninstall

Puede incluir guiones que serían ejecutados antes y después de la instalación o desinstalación de paquetes binarios. Una razón importante para esto es hacer cosas como ejecutar ldconfig tras la instalación o eliminar paquetes que contienen librerías compartidas. Las macros para cada uno de los guiones son:

%pre es la macro para los guiones pre-instalación.
%post es la macro para los guiones post-instalación.
%preun es la macro para los guiones pre-desinstalación.
%postun es la macro para los guiones post-desinstalación.

Los contenidos de estas secciones deben ser solamente guiones sh, luego no resulta necesaria la línea #!/bin/sh.

6.8 `%files`

Esta es la sección donde debe listar los ficheros del paquete binario. RPM no tiene forma de saber qué ficheros binarios se han instalado tras ejecutar make install. NO hay forma de saberlo.

Algunos han sugerido ejecutar un comando find antes y después de la instalación del paquete. En un sistema multiusuario, esto es inaceptable ya que pueden crearse otros ficheros durante la construcción del paquete que no tienen nada que ver con el mismo.

También hay algunas macros disponibles para hacer cosas especiales. Son las listadas a continuación:

%doc se usa para señalar los ficheros de documentación del paquete fuente que desea que sean instalados en una instalación binaria. La documentación será instalada en /usr/doc/$NOMBRE-$VERSIÓN-$PUBLICACIÓN. La lista podrá incluir varios ficheros en una sóla línea o puede listarlos de forma separada con una macro para cada uno de ellos.
%config se usa para señalar los ficheros de configuración en un paquete. Ficheros así pueden ser sendmail.cf, passwd, etc. Si posteriormente desinstala un paquete que incluye ficheros de configuración, todos los ficheros sin modificar serán borrados y todos los ficheros modificados serán movidos a su nombre antiguo con el sufijo .rpmsave añadido a su nombre. También puede incluir múltiples ficheros con esta macro.
%dir señala a un único directorio en la lista como propiedad de un paquete. Por defecto, si incluye en la lista un nombre de directorio SIN una macro %dir, TODO el contenido de ese directorio es incluido en la lista de ficheros y posteriormente instalado como parte del paquete.
%files -f <nombredefichero> le permitirá tener la lista de ficheros contenida en un fichero situado en el directorio de las fuentes. Resulta útil en los casos en los que un paquete puede crear su propia lista de ficheros por sí mismo. En ese caso sólo tendrá que incluir el nombre de ese fichero aquí y no necesitará especificar nada más.

La mayor precacución que debe tener en cuenta en la lista de ficheros es la inclusión de directorios. Si por accidente incluye /usr/bin, su paquete binario contendrá todos los ficheros contenidos en el directorio /usr/bin en su sistema.

6.9 Construcción

``El Árbol de Directorios de los Fuentes''

Lo primero que necesita es un árbol de directorios de compilación configurado de forma apropiada. Esto se puede hacer mediante el fichero /etc/rpmrc. La mayoría de la gente sólo usará /usr/src.

Puede que necesite crear los siguientes directorios para organizar un árbol de construcción:

BUILD es el directorio donde RPM lleva a cabo toda la construcción. No tiene que llevar a cabo su prueba de construcción en ningún sitio en particular; aquí es donde RPM llevará a cabo la compilación y empaquetamiento.
SOURCES es el directorio donde debe situar los ficheros fuente originales y los correspondientes parches. Es donde RPM buscará por defecto.
SPECS es el directorio donde deben ir situados los ficheros spec.
RPMS es donde RPM dejará los paquetes RPM binarios una vez construidos.
SRPMS es donde RPM dejará los paquetes RPM fuentes.

Prueba de construcción

Lo primero que querrá hacer es asegurarse que los fuentes se construyen adecuadamente sin usar RPM. Para ello, desempaquete los fuentes, sitúese en el directorio $NAME.orig. De nuevo desempaquete los fuentes. Use éstos para compilar. Vaya al directorio de los fuentes y siga las instrucciones para construirlo. Si necesita editar algo, necesitará un parche. Una vez que lo tenga compilado, limpie el directorio fuentes.

Asegúrese que borra todos los ficheros creados por algún guión de configuración. Haga entonces un cd hacia arriba, al directorio paterno. Deberá hacer algo como:


diff -uNr nombredirectorio.orig nombredirectorio > ../SOURCES/nombredirectorio-linux.patch

Lo que creará un parche que podrá usar en su fichero spec. Advierta que el ``linux'' que aparece en el nombre del parche es sólo un identificador. Usted probablemente querrá usar algo más descriptivo como ``config'' o ``bugs'' para describir el porqué del parche. También es buena idea examinar el fichero parche que ha creado antes de usarlo para asegurarse de que no se han incluido binarios por error.

Creación de la Lista de Ficheros

Ahora que tiene los fuentes listos para construir y sabe cómo hacerlo, constrúyalo e instálelo. Examine la salida de la secuencia de instalación y construya su lista de ficheros a partir de ahí para incluirla en el fichero spec. Normalmente nosotros construimos el fichero spec en paralelo a todos estos pasos. Usted puede crear uno inicial y rellenar las partes sencillas e ir rellenando el resto conforme vaya completando los diferentes pasos.

Construyendo el paquete con RPM

Una vez que tenga su fichero spec, está listo para intentar construir su paquete. La forma más útil de hacerlo es con un comando como el siguiente:


        rpm -ba foobar-1.0.spec

Hay otras opciones útiles con el parámetro -b tales como:

p obliga a ejecutar solamente la sección prep del fichero spec.
l efectúa algunos chequeos en %files.
c ejecuta la sección %prep y compila. Resulta útil cuando no está seguro de si sus fuentes compilan completamente. Puede parecer inútil porque usted tal vez quiera jugar solamente con los fuentes hasta que compilen y usar entonces RPM, pero una vez que se haya acostumbrado a usar RPM, encontrará ocasiones en las que podrá usarla.
i ejecuta las secciones prep, compile e install.
b ejecuta las secciones prep, compile e install y construye el paquete binario.
a ejecuta las secciones prep, compile e install y construye los paquetes binario y fuentes.

Hay varios modificadores para el parámetro -b. Son los siguientes:

--short-circuit El proceso de construcción comenzará directamente por la fase especificada, saltándose las previas a la indicada. (Sólo puede ser empleado en conjunción con c e i).
--clean elimina el árbol de construcción una vez que ha concluido.
--keep-temps mantendrá todos los ficheros temporales y los guiones que estuvieran en /tmp. Podrá saber qué ficheros fueron creados allí usando el parámetro -v.
--test No lleva a cabo ninguna fase realmente, pero mantiene todos los ficheros temporales.

6.10 Probándolo

Una vez que tenga los paquetes rpm binario y fuentes, necesitará probarlos. La mejor forma y la más sencilla es usar para el test una máquina completamente diferente de la que usó para la construcción. Después de todo, ha hecho un montón de make install en su máquina por lo que debería haber quedado instalado de forma aceptable.

Puede ejecutar un rpm -u nombredepaquete al paquete a probar, pero puede ser decepcionante porque en la construcción del paquete usted hizo un make install. Si se dejó algo fuera de la lista de ficheros, no será desinstalado. Reinstale entonces el paquete binario y su sistema estará completo de nuevo, aunque no el paquete rpm. Asegúrese y tenga en mente que sólo porque usted hace rpm -ba package; la mayoría de la gente instalará su paquete sólo con rpm -i package.

Asegúrese también de que no hace nada en las secciones build o install que necesite hacerse cuando los binarios se instalan por sí mismos.

6.11 �Qué hacer con los nuevos paquetes RPM?

Una vez que ha hecho su propio RPM de algo (asumiendo que no ha sido empaquetado en RPM con anterioridad), puede contribuir con su trabajo a otras personas (asumiendo igualmente que el paquete en RPM es libremente distribuible). Para hacerlo, puede querer subirlo a ftp.redhat.com.

6.12 �Y ahora qué?

Por favor mire las secciones anteriores sobre pruebas y qué hacer con los nuevos RPM. Queremos todos los paquetes RPM disponibles que podamos conseguir, y queremos que estén correctamente empaquetados. Por favor, tómese el tiempo de probarlos adecuadamente y de subirlos para el beneficio de todos.

También, por favor asegúrese de que no está haciendo llegar solamente software de libre disposición. Software comercial y shareware N.T.: Probar antes de comprar no deberían ser subidos a menos que esté claramente permitido en alguna cláusula de su licencia. Esto incluye el software de Netscape, ssh, pgp, etc.

Anterior Siguiente Indice