De Wiki de la Comunidad Mandriva

Tabla de contenidos 1 Prólogo 2 Instalar el software 2.1 Lo básico 2.2 Construir para Mandriva Linux 3 Tareas preliminares 3.1 Instale los paquetes necesarios 3.2 Cree las carpetas necesarias 3.3 Cree el fichero .rpmmacros 4 Construyendo un RPM 4.1 Desde un RPM de código fuente ya existente 4.2 Desde el código fuente 'en bruto' 4.2.1 Revisiones preliminares 4.3 En el interior del fichero de especificaciones 4.3.1 Sección Header 4.3.2 Sección Prep 4.3.3 Sección Build 4.3.4 Sección Install 4.3.5 Sección Files 4.3.6 Sección Changelog (registro de cambios) 4.4 La construcción 4.5 Optimice la construcción 5 Probar un RPM 5.1 Pruebas básicas 5.2 Hilando (linting) el paquete 5.3 Prueba de instalación 6 ¿Algo va mal? 6.1 Para problemas generales de RPM: 6.2 Para problemas específicos de RPM Mandriva: 7 Sobre los scripts Pre- y Post-instalación 7.1 Nociones básicas 7.2 Tratando con actualizaciones 8 Más macros 9 Interacción con urpmi y rpmdrake 10 Grupos de Mandriva Linux 11 Licencias válidas para Mandriva Linux 12 Algunos enlaces 13 Otras fuentes interesantes de información sobre RPM en Mandriva 14 Glosario

Este manual está dirigido a ayudar a personas que desean producir paquetes de software que se integren bien en la distribución GNU/Linux Mandriva Linux. En particular, se hará hincapié en las pequeñas diferencias respecto a los paquetes que otras personas puedan crear para otras distribuciones basadas en rpm. Este documento debería ser útil para desarrolladores de Mandriva, pero tambien para personas ajenas a la empresa. Un anexo que cubre los aspectos más avanzados se puede encontrar en RPM Avanzado

La distribución GNU/Linux Mandriva Linux es producida y publicada por Mandriva, Inc., con la ayuda de numerosos contribuidores, probadores, traductores. Algunos de ellos son citados en Distro Credits

[editar] Prólogo

En éste documento se asume que el lector está "preparado para linux" (linux-ready). Se supone que conoce los comandos básicos, la estructura de directorios y ya ha usado rpm al menos para instalar paquetes.

Éste documento se construye como una receta paso-a-paso para obtener un paquete rpm que se integre bien en la distribución Mandriva Linux, partiendo ya sea desde un rpm de código fuente (source rpm) o desde un archivo tar de código fuente.

Si aún no lo ha hecho, debería usted leer Como Cooker, que explica el proceso de desarrollo de Mandriva Linux.

Llanamente, RPM significa tres cosas:

• un programa orientado a instalar o crear paquetes,
• un formato usado en paquetes (de código fuente o binario) creados por el programa rpm,
• un fichero llamado paquete que contiene ya sea código fuente o programas ejecutables además de una cabecera de información sobre cómo instalar/desinstalar el programa.

El programa rpm es, desde el punto de vista del usuario, un potente administrador de paquetes. Actúa como "conductor" de cualquier acción que se realice sobre los paquetes rpm. Entre otras cosas, puede:

• instalar o actualizar un paquete verificando sus dependencias,
• mientras instala un paquete, ejecuta acciones para dejar el programa instalado y listo para usarse,
• restaurar ficheros accidentalmente borrados que pertenezcan a un paquete,
• indicar si un paquete ya está instalado,
• encontrar a qué paquete pertenece un fichero particular,
• verificar que la instalación actual satisface las necesidades de dependencias de paquetes instalados,
• ....

Desde el punto de vista del programador, el programa rpm es un empaquetador que encapsula en un simple rpm toda la información necesaria para instalar un programa sobre una plataforma dada.

Es importante distinguir desde el principio la diferencia entre paquetes de código fuente .src.rpm y de programas binarios .<arquitectura>.rpm.

El primero contiene (como usted podría adivinar) el árbol completo de código fuente del programador original, además de todo lo necesario que el empaquetador añadió para configurar, compilar e instalar el programa. Generalmente consiste en un fichero de especificaciones (el fichero usado para indicar a rpm qué ha de ejecutar para crear el paquete) además de parches de correcciones, si hubiera alguno.

El segundo contiene el programa binario compilado, y todos los ficheros (documentación, ficheros de configuración, iconos,...) que serán instalados en el sistema. También contiene el procedimiento usado para colocar los ficheros en su ubicación correcta y las acciones que ha de ejecutar para dejar el programa en condiciones de operación.

[editar] Instalar el software

[editar] Lo básico

Aunque RPM fué originalmente diseñado para trabajar con Red Hat Linux, también trabaja sobre otras distribuciones basadas en rpm: Mandriva Linux, Suse, Fedora, CentOS, etc ; rpm ya está instalado en esos sistemas.

Puede obtener la distribución 'vanilla' de rpm desde Red Hat, aquí: [1]

El rpm binario que usted construirá para Mandriva Linux no trabajará con otras distribuciones, aunque Mandriva hace todo lo posible para mantenerse compatible con Red Hat.

[editar] Construir para Mandriva Linux

Construir paquetes para Cooker (por ejemplo, la versión de desarrollo de Mandriva Linux) siempre está sujeto a pequeños parches y mejoras del programa rpm en uso. Abra cualquier mirror de Mandriva Cooker y obtenga:

• El paquete rpm, que es nuestra versión parcheada de la de Red Hat.
• El paquete rpm-build, que contiene scripts usados para construir paquetes.
• El paquete spec-helper, que es una herramienta que reduce al mínimo los ficheros de especificaciones (spec files) haciendo cosas automáticamente, como quitar los símbolos de depuración de los programas binarios (stripping) y comprimir las páginas man (manuales).
• El paquete libtool, que es utilizado por algunos scripts de configuración para construir librerías compartidas.
• El paquete rpmlint, que se usa para verificar la validez del src.rpm.

[editar] Tareas preliminares

[editar] Instale los paquetes necesarios

Para poder construir RPMs, usted debe tener el paquete rpm-build instalado. Para obtener instrucciones sobre la instalación de paquetes, consulte Instalar_y_quitar_software.

[editar] Cree las carpetas necesarias

Para construir paquetes, rpm necesita un árbol especial en su directorio home. Este árbol puede ser creado con el siguiente comando: mkdir -p ~/rpm/{BUILD,RPMS/$ARCH,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp} . Sustituya $ARCH por la(s) arquitectura(s) para la(s) que usted planea construir paquetes. Basicamente es i586, pero tambien puede ser x86_64/sparc/alpha/ppc.

¡NOTA! Construir RPM's como usuario root es peligroso, porque los ficheros binarios se instalan en el sistema antes de ser empaquetados, así que usted siempre debe construirlos como un usuario normal para que su sistema no quede sucio.

Asegúrese de que el árbol tiene ésta forma:

• ~/rpm/BUILD: El directorio donde los códigos fuente se construyen.
• ~/rpm/RPMS: Contiene los directorios, uno por cada arquitectura, que recibirán posteriormente los ficheros binarios compilados.
• ~/rpm/RPMS/i586: El directorio donde se almacenarán los paquetes rpm para procesadores i586.
• ~/rpm/RPMS/x86_64: El directorio donde se almacenarán los paquetes rpm para procesadores AMD64.
• ~/rpm/RPMS/noarch: El directorio donde se almacenarán los paquetes rpm que sean independientes de la arquitectura del procesador.
• ~/rpm/SOURCES: Los ficheros de código fuente (mipaquete.tar.bz2, por ejemplo).
• ~/rpm/SPECS: Los ficheros de especificaciones que tendremos que construir.
• ~/rpm/SRPMS: El rpm de código fuente tras su construcción.
• ~/rpm/tmp: Para cosas temporales que rpm creará cuando construya sus paquetes.

Nota: Los directorios de arquitectura bajo ~/rpm/RPMS son necesarios para rpm. Si no existen, obtendrá un mensaje de error.

[editar] Cree el fichero .rpmmacros

Para poder construir paquetes para Mandriva Linux, necesitará añadir el fichero de configuración .rpmmacros en su directorio home:

%_topdir                %(echo $HOME)/rpm
%_tmppath               %(echo $HOME)/rpm/tmp

# Si desea que sus paquetes sean automáticamente firmados con GPG, añada estas
# tres líneas cambiando 'Mandrivalinux' por su nombre GPG. Tambien puede usar
# rpm --resign para firmarlos posteriormente.
%_signature             gpg
%_gpg_name              Mandrivalinux
%_gpg_path              ~/.gnupg

# Agregue su nombre y dirección de correo electrónico en el campo %packager. 
# Puede que tambien desee cambiar 'vendor' por usted mismo.
%packager               John Doe <[email protected]>
%distribution           Mandriva Linux
%vendor                 Mandriva

# Si desea que sus paquetes tengan su propio sufijo de distribución en lugar 
# de mdv, anótelo aquí 
%distsuffix             foo

Aviso, no cambie %optflags, porque ya hay uno provisto para su sistema en /usr/lib/rpm/mandriva/rpmrc.

Su programa rpm está ya preparado para construir paquetes. Todo lo hecho anteriormente puede hacerse de una sola vez (para i586) ejecutando éste Script de instalación RPM.

[editar] Construyendo un RPM

[editar] Desde un RPM de código fuente ya existente

Este es generalmente el caso de paquetes que ya están incluidos en la distribución.

Los más recientes ficheros rpm de cooker están disponibles en muchos mirrors cuya lista está disponible en Mirrors de Cooker. En sus directorios puede encontrar:

• SRPMS para rpms de código fuente (main, contrib, jpackage, otros) y bajo la arquitectura del procesador (por ejemplo, i586, x86_64, ...):
• media/main para rpms de programas binarios de la distribución principal.
• media/contrib para rpms de programas binarios que son contribuciones de terceros.
• media/jpackage para rpms que son programas binarios independientes de la arquitectura del procesador (noarch).

Cuando usted encuentra el rpm de código fuente que quiere modificar para Mandriva Linux, simplemente ejecute rpm -ivh mipaquete.src.rpm; esto instalará todos los ficheros de código fuente en su directorio RPM. Usted tambien puede usar urpmi para descargarlo e instalarlo.

Por ejemplo:

[camille@kenobi ~/rpm]$ rpm -i /cooker/SRPMS/ktron-1.0.1-2mdk.src.rpm 
[camille@kenobi ~/rpm]$ ls -R * 
SRPMS:
SPECS:
ktron.spec
SOURCES:
ktron-1.0.1.tar.bz2
RPMS:
noarch/ i686/ i586/ i386/
BUILD: 

Podemos ver que rpm ha instalado en nuestro árbol RPM el fichero de código fuente ktron-1.0.1.tar.bz2 y el fichero de especificaciones. Aún antes de construir una versión más nueva de un paquete, sería interesante para usted reconstruir el paquete actual para que pueda entender cómo se compila y si se compila. El comando mágico para hacer esto es rpmbuild con la opción buildall:

[camille@kenobi ~/rpm]$ cd ~/rpm/SPECS
[camille@kenobi ~/rpm]$ rpmbuild -ba ktron.spec
[camille@kenobi ~/rpm]$ ls -l ~/rpm/RPMS/i586/ktron-1.0.1-2mdk.i586.rpm
[camille@kenobi ~/rpm]$ ls -l ~/rpm/SRPMS/ktron-1.0.1-2mdk.src.rpm

Si la construcción termina sin errores (pueden pasar horas según sea el paquete, como en el caso del kernel), tendrá el rpm binario y el rpm fuente en los subdirectorios ~/rpm/RPMS/i586 y ~/rpm/SRPMS/, respectivamente. Si quiere instalar el rpm binario, debe hacerlo como 'root', al cual puede obtener acceso escribiendo su (para posteriormente terminar con la combinación control_d, o escribiendo 'exit'). Pero para construir un rpm, o expandir un src.rpm, nunca es necesario ser root.

El registro de la construcción puede ser muy largo y se puede guardar para revisarlo posteriormente. El autor usa emacs o xemacs en una segunda ventana con un shell (shell Alt-x) y guarda la salida dándole un nombre, como ktron.log, por ejemplo, cuando termina. (I am using emacs or xemacs and use a second window with a shell (Alt-x shell) and save the buffer as ktron.LOG, for example, when finished.)

En el subdirectorio ~/rpm/BUILD tendrá acceso usualmente a los códigos fuentes ya corregidos (si uno o más parches han sido proporcionados en ~/rpm/SOURCES), los programas binarios, las páginas del manual, etc. El fichero spec describe los ficheros fuente y los parches, cómo construir el paquete y cómo instalarlo.

Ahora, todo lo que necesitamos hacer, en caso de mejorar ktron, es modificar el fichero de especificaciones y reconstruir entonces el paquete.

Es importante mencionar que cada paquete mantenido en Mandriva se almacena en un sistema CVS (sistema de control de versiones). Esto permite que sea registrado cada estado del paquete para que el desarrollador pueda consultar el archivo para revisar anteriores modificaciones y, en caso necesario, volver a una versión anterior.

Cada fichero de especificaciones se almacena en un módulo llamado SPECS/<paquete> o contrib-SPECS/<paquete>. Puede acceder a él en http://cvs.mandriva.com/

Para detalles sobre cómo acceder al sistema CVS, consulte las páginas CVS de Mandriva Linux (¿..., consult the Mandriva Linux CVS pages?)

[editar] Desde el código fuente 'en bruto'

Por ejemplo: ha encontrado un interesante programa en Freshmeat o en Sourceforge que le avisa cuando el té está listo y a usted le hace gracia que esté disponible para los amantes del té de Mandriva Linux. Probablemente, la mejor forma de hacer ésto es construir un RPM que funcione conforme a los estándares de Mandriva.

Descargue el archivo tarball y guardelo en el directorio ~/rpm/SOURCES.

[editar] Revisiones preliminares

Licencia

A pesar de la prevalencia de las licencias GPL, hoy en día aún están en uso un número de licencias no-GPL. Revise cuidadosamente la licencia del programa para determinar si puede o no ser incorporado a la distribución. No podemos aceptar software propietario cerrado, aunque hay algunas excepciones para el club. Tampoco podemos aceptar programas que no permitan su libre distribución. Deje de lado estos programas. Se puede encontrar una lista de licencias y de software aceptable en Mandriva Licenses

Compresión bz2

Para ahorrar espacio en el paquete se recomienda comprimir los archivos en formato bzip2. La mayoría de las veces el código fuente será entregado en archivos .tar.gz. Ante todo, conviértalo en un .tar.bz2 (que debería ser más pequeño), usando bzme proporcionado por el paquete de Mandriva bzip2. Evite comprimir parches en formato texto (como los producidos por diff y similares) y otros ficheros de texto de configuraciones/scripts/etc. porque usualmente se salva poco espacio, mientras se hace más dificil ver los cambios en Subversion (además, Subversion ya usa alguna forma de compresión). Nota: para paquetes de alto riesgo y seguridad crítica recomendamos que usted no modifique el código fuente original, dado que modificaría la firma o el checksum (comprobación de paridad). Para este tipo de paquetes recomendamos que los deje en el formato original, de forma que si alguien ejecuta md5/gpg sobre el paquete, el resultado coincida con los valores listados en el sitio de descarga. Un ejemplo en el que es aplicable esta excepción sería OpenSSH.

[editar] En el interior del fichero de especificaciones

Bien, aquí estamos. Esta es la sección más importante de este documento. El fichero de especificaciones contiene toda la información que rpm necesita para:

1. compilar el programa y construir los paquetes rpm, el de fuentes y el de binarios,
2. instalar y desinstalar el programa en la máquina del usuario final.

El hecho de que estos dos tipos de información se combinen en un sólo fichero puede resultar confuso para el principiante. Realmente, esto es debido al arbol de fuentes, que ya contiene esa información. Como el procedimiento de instalación se extrae del proceso de instalación generalmente ejecutado por 'make install' en el arbol de fuentes, ambas partes están estrechamente unidas.

En resumen, el fichero de especificaciones describe una compilación e instalación "simuladas", le dice a rpm qué ficheros de ésta instalación van a ser empaquetados, y cómo finalmente instalar éstos ficheros en el sistema del usuario. Los comandos son ejecutados usando el shell /bin/sh, así que cosas como [ -f configure.in ] && autoconf son válidas.

No es intencionado explicar con detalle todas las características de un fichero de especificaciones. El libro Maximum RPM (ver Sección 7) explica esto en profundidad. Todo lo que vamos a hacer aquí es revisar rápidamente todas las características usadas en un fichero de especificaciones estándar de Mandriva.

Este es un ejemplo del repositorio de cooker. Puede considerar nuestra plantilla de ficheros de especificaciones para empezar uno desde el principio.

A medida que vaya construyendo más y más RPMs, descubrirá que hay algunas opciones sobre las que no le hemos explicado nada. RPM es extremadamente extensible, así que encontrar estas opciones se deja como un ejercicio para el lector. Siempre es una buena práctica abrir algunos ficheros de especificaciones para echarles un vistazo y ver cómo trabajan.

Puede ver aquí una lista de especificaciones y parches.

%define name    gif2png 
%define version 2.0.1 
%define release %mkrel 1 

Name:           %{name} 
Summary:        Tools for converting websites from using GIFs to using PNGs 
Version:        %{version} 
Release:        %{release} 
Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 
Source1:        %{name}-%{version}-mdk-addon.tar.bz2 
Patch0:         gif2png-2.0.1-bugfix.patch.bz2 
URL:            http://www.tuxedo.org/~esr/gif2png/ 

Group:          Applications/Multimedia 
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot 
License:        MIT-like 
Requires:       python 

%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files
to PNG files. The Python script web2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.

%prep 
%setup -q -a 1 
%patch -p1 

%build 
%configure 
%make

%install
rm -rf $RPM_BUILD_ROOT
%makeinstall

%clean 
rm -rf $RPM_BUILD_ROOT 

%files 
%defattr(0755,root,root) 
%doc README NEWS COPYING AUTHORS 
%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*
%{_bindir}/gif2png 
%{_bindir}/web2png 

%changelog 
* Mon Nov 02 1999 Camille Begnis <[email protected]> 2.0.1-1mdk
- Upgraded to 2.0.1 

* Mon Oct 25 1999 Camille Begnis <[email protected]> 2.0.0-1mdk
- Specfile adaptations for Mandrake
- add python requirement
- gz to bz2 compression

Analicemos en detalle cada línea de este fichero:

Vaya con cuidado, un % al principio de una línea puede tener diversos significados :

• el principio de una sección (prep, build, install, clean)
• una macro de un script de línea de comandos (setup, patch)
• una directiva usada por una sección especial (defattr, doc, ...)

[editar] Sección Header

%define name    gif2png
%define version 2.0.1
%define release %mkrel 1

Estas tres líneas definen constantes que deberían ser usadas en muchas de las secciones posteriores del fichero de especificaciones; son llamadas %{name} , %{version} y %{release} . %mkrel es una macro de Mandriva que debería ser usada para añadir 'mdv' tras el número de versión, vea Etiqueta específica de la versión de la Distribución (en inglés).

Ahora, podemos rellenar algunos campos de información para rpm :

Name:           %{name}

El nombre del paquete, usado como nombre en la base de datos de paquetes en la máquina del usuario.

Note que la macro "%{name} " es una referencia a la definición inicial.

Version:        %{version}
Release:        %{lanzamiento}

En este punto debemos explicar cómo se forma el nombre del paquete. Es importante que siempre se respete éste estándar para hacer que su trabajo sea entendido por otros.

Hay tambien algunas etiquetas que usted querría conocer, pero que no están en el fichero de especificaciones del ejemplo. Hay algunas que usted se podría encontrar. No se espera que usted recuerde todas si acaba de empezar a construir rpms, pero despues de un tiempo, ¡esta lista será una buena referencia!.

• Un paquete binario es nombrado como: nombre-version-lanzamiento.arqu.rpm
• Un paquete de fuentes es nombrado como: nombre-version-lanzamiento.src.rpm (por ejemplo gif2png-2.0.1-1mdk.src.rpm en nuestro ejemplo)

Como nombre se escoge generalmente el del programa binario principal, así que piense en una buena razón si desea cambiar el nombre.

La versión es la de los fuentes sin parches aplicados. Es el número de versión del archivo original: nombre-version.tar.gz.

El lanzamiento es un número seguido por 'mdv' (que equivale a 'Mandriva', ésto es absolutamente obligatorio) que se incrementa con cada nueva construcción del paquete. Una nueva construcción puede ser debida a la aplicación de parches en el código fuente, una modificación en el fichero de especificaciones, la adición de un icono, etc.

Summary: tools for converting websites from using GIFs to using PNGs

Ésta es la descripción del paquete abreviada a una sola línea.

Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 

Ésta línea le indica a rpm cual es el archivo de código fuente que debe utilizar para la construcción del paquete. Fíjese en que el nombre del archivo está precedido por una URL (dirección de internet) completa, que apunta al sitio de internet donde está disponible el archivo original de código fuente; rpm quitará la dirección, dejando sólo el nombre del archivo, y lo buscará en el directorio SOURCES. Aunque ésta dirección es opcional, es muy recomendable para que otras personas sepan dónde obtener nuevo código fuente para actualizarlo y volver a compilarlo. Ésto permitirá a herramientas como rpmbuildupdate construir automáticamente nuevas versiones (vea rpmbuildupdate (en inglés) para más información).

Cuando hay más de un archivo de código fuente, añada más líneas como Source1: (otro archivo)..., Source2: (otro archivo más)..., etc.

Patch0:         gif2png-2.0.1-bugfix.patch.bz2

Aunque sea opcional, he aquí dos razones para usar ésta etiqueta:

1. Usted ha corregido un error en el código fuente. Así que usted ha generado un fichero parche que debería ser aplicado al código fuente original antes de su compilación.
2. Usted ha sido avisado de la existencia en internet de un parche para su versión del programa, y la ha descargado.

Tome nota de que el fichero parche debe ser guardado en el directorio SOURCES; como con los archivos de código fuente, pueden haber varios parches, que deberán ser indicados como Patch1, Patch2, etc.

URL:            http://www.tuxedo.org/~esr/gif2png/

Ésta línea (opcional, aunque muy recomendada) apunta a la página original del programa.

Group:          Multimedia

Ésto le indica a rpm en qué parte del arbol general de paquetes debe figurar éste paquete. Esta característica se usa por los administradores gráficos de paquetes como rpmdrake o kpackage.

La estructura completa de grupos que se ha de usar, que es diferente de la usada por Red Hat, se puede encontrar en la página Grupos de RPM (en inglés). Es obligatorio seguirla; si no, su paquete se mezclará con otros en el árbol de selección del instalador de Mandriva Linux o en los administradores gráficos de paquetes.

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot

Ésta línea es muy importante y no puede ser omitida. Le indica a rpm que, para instalar el programa, tendrá que usar un directorio root especial (un / falso) en la máquina compiladora. Hay dos razones para esto:

1. Durante la construcción de un rpm usted no tiene acceso total a la máquina, por lo que no puede instalar el paquete en los directorios normales.
2. La instalación en el árbol normal de trabajo de la máquina compiladora probablemente mezclaría los ficheros del paquete con otros, y, aún más importante, sería peligroso si el paquete ya está instalado. A mucha gente le gusta usar /var/tmp o /tmp para la simulación del directorio / durante la construcción. Esto no es necesariamente un problema si usted es el único usuario de la máquina, pero si tiene múltiples usuarios en su máquina y varios compilan a la vez el mismo paquete, rpm fallará. Por lo tanto, es importante que usted defina %{_tmppath} , y ¡dentro de su propio directorio "home"!

License:        MIT-like

Ésta etiqueta (reemplazando el Copyright) define la licencia elegida por el poseedor de los derechos del programa. Ésta licencia se aplicará sobre el programa que se empaqueta. En la mayoría de los casos es GPL. Vea en Licencias Mandriva una lista completa de licencias válidas.

Requires:       python

Esta línea se ha añadido porque uno de los programas incluidos en el paquete es un script de python. Es, pues, necesario que python funcione. Puede indicar una versión mínima (o igual). Por ejemplo: Requires: python >= 1.5.1

%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files
to PNG files. The Python script web2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.

Ésta es una etiqueta bastante especial en la cabecera del fichero de especificaciones, debido a que es un texto completo formado por varias líneas y párrafos, si es necesario. Contiene la descripción completa del programa que se instalaría, de forma que ayude al usuario a decidir si quiere o no instalar el paquete.

Usted se debe estar preguntando en este momento: "¿Y qué pasa con las traducciones?". Realmente, para mejorar la lectura de los ficheros de especificaciones, las traducciones de las etiquetas resumen y descripción se guardan en un fichero especial llamado <paquete>.po.

Estos ficheros se guardan en el módulo poSPECS, en el cvs de Cooker. Cuando se crea un nuevo paquete, el fichero <paquete>.po básico se crea automáticamente en éste módulo para futuras traducciones.

Éste método implica que todo el texto escrito en un fichero .spec se escriba en inglés, con la excepción, sin embargo, de paquetes orientados a un idioma particular (ispell-es, por ejemplo). En éste caso se recomienda escribir el texto en dos idiomas: inglés y el idioma particular de éste paquete. Usted tendrá que usar etiquetas especiales para ésto: Summary(es): ... y %description -l es.

[editar] Sección Prep

%prep  
%setup -q -a 1
%patch0 -p1

En ésta sección se escribe el primer script que ejecuta rpm. Su papel es:

• crear el directorio principal de construcción (dentro de BUILD),
• desempaquetar los códigos fuente originales en el directorio de construcción,
• aplicar los ficheros de parches al código fuente.

Debería continuar con cualquier comando que el empaquetador desee para dejar el código fuente en un estado listo para compilar.

%setup -q -a 1 

Ésta es una macro de script ya preparada para

• cambiar al directorio de construcción
• extraer el/los código(s) fuente (silenciosamente, -q)
• cambiar el propietario y permisos de los ficheros fuente.

De forma predeterminada, extrae el primer archivo de código fuente; usted debe usar parámetros para cualquiera de los otros archivos, en nuestro ejemplo -a 1 le dice que tambien queremos la extracción del archivo de código fuente número 1.

Hay otros parámetros interesantes que se pueden usar con la macro %setup:

• -c nombre - El parámetro -c describe que primero se crea un directorio nombre; entonces se cambia a ese directorio nombre y ahí se desempaqueta Source0. Esto es útil cuando algunos paquetes están empaquetados de forma inapropiada y, cuando se expanden, no generan primero un directorio en el que expandirse.
• -D - no borrar el directorio antes de desempaquetar. Ésto es util sólo si usted tiene más de una macro setup. Sólo debe usarse en macros setup que siguen a la inicial (nunca debe usarse en la primera macro).
• -T - esta opción anula la acción predeterminada de desempaquetar el archivo de código fuente y necesita un -b 0 o un -a 0 para desempaquetar el archivo de fuentes principal. Necesita ésto cuando hay archivos de código fuente secundarios.
• -n nombre - si el nombre del rpm es algun otro diferente del resultante de desempaquetar el archivo, utilice éste parámetro. Por ejemplo: si el nombre del rpm es programa-version-revision y el fuente se desempaqueta como programa-version-fecha, el proceso de construcción no podrá cambiar al directorio programa-version, por lo que tendrá que utilizar -n programa-version-fecha, de forma que rpm sabrá el directorio en el que continuar.

%patch0 -p1

La macro responsable de aplicar el parche al código fuente; su parámetro "-p<numero>" se pasa al programa de parcheado. Si usted tiene otro parche declarado Patch1: ... en la sección Header, debería añadir otra línea: %patch1 -p1. Añadir un -b .su_sufijo sería bueno también, de forma que usted permite saber a otros qué hace su parche de corrección, o quien hizo el parche. Por ejemplo, si Alfredo hizo el parche, entonces podría ser %patch -p1 -b .alfredo, o si lo hizo Barney sería %patch -p1 -b .barney.

[editar] Sección Build

%build 

Ésta sección contendrá el script responsable de la generación real del programa.

Consiste en los comandos necesarios para construir un paquete desde un árbol de código fuente desempaquetado.

%configure

Ésta es la línea usada para configurar código fuente autoconfigurado. %configure ejecuta un ./configure con muchos pre-establecimientos como

export CFLAGS="$RPM_OPT_FLAGS"

antes del 'configure', y opciones como

i586-mandrake-linux --prefix=/usr --datadir=/usr/share

etc.

Algunas veces éstos argumentos no son soportados por el script configure. En éstos casos, usted debe descubrir la razón, y ejecutar el ./configure con los parámetros adecuados. Especifique la plataforma objetivo en la orden configure, si está soportada, con %{targetplatform} ; por supuesto, se debe evitar la determinación de una arquitectura en ficheros de especificaciones; sobre ix86, se convertirá en i586-mandrake-linux, como se muestra en el ejemplo que aparece sobre éste texto.

Tenga en cuenta que necesitará el paquete libtool para usar %configure con paquetes que construyen librerías compartidas.

Cuando se construye, y cuando se prueba su paquete, usted debería verificar que el ordenador objetivo es realmente un i586; en particular, cuando se compila sobre un tipo de procesador superior, el comportamiento predeterminado del script 'configure' es descubrir su procesador y optimizarlo para éste. El objetivo de la macro %configure es evitar éste comportamiento.

%make

Ésta es una macro simple que básicamente ejecuta un 'make' con el adecuado parámetro de multiprocesador -j<num>.

Para códigos fuente que usan xmkmf, debería reemplazar lo siguiente con:

make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS" 

Para otros paquetes, en muchos casos (aunque no todos) un simple 'make' funcionará.

[editar] Sección Install

%install 

Ésta sección contendrá el script responsable de llevar a cabo la instalación en la simulación de directorios: $RPM_BUILD_ROOT.

Tendrá programados todos los comandos necesarios para dejar el programa listo para usar en el sistema del futuro usuario.

rm -rf $RPM_BUILD_ROOT

Éste es el primero de los comandos que se ejecutarán en la sección %install; limpia un probablemente ya existente directorio de instalación de una versión anterior.

%makeinstall

Ésta línea instala finalmente el programa en la simulación del directorio de instalación. Ésta macro se convertirá en un "make install" con diversas opciones que le permitirán instalarlo en la simulación de directorios $RPM_BUILD_ROOT, por ejemplo

prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir}

etc.

En algunos casos, el script 'configure' puede estar parcialmente estropeado y necesitará buscar en 'Makefiles' hasta averiguar los parámetros adicionales necesarios para instalarlo correctamente. Uno de los casos más comunes es que a veces usted tendrá que usar 'make DESTDIR=$RPM_BUILD_ROOT install'. (N. del T.: Pendiente de probar para ver si la traducción es correcta. El original dice "In some cases the configure script will be partially broken and you may need to lurk in the Makefiles to guess the additional parameters to have it install correctly. One of the most common ones is that sometimes you have to use make DESTDIR=$RPM_BUILD_ROOT install.")

Para ahorrar tanto espacio en disco como tiempo de descarga, Mandriva usa bzip2 para comprimir páginas 'man-pages' e 'info-pages'. Sin embargo, éste aspecto es manejado directamente por el programa rpm personalizado por Mandriva. En éste punto del fichero de especificaciones, los paquetes más antiguos contenían algunas líneas similares a 'find $RPM_BUILD_ROOT%{_mandir} -type f -exec bzip2 -9f {} \;'. Es el mismo caso que las líneas '$RPM_BUILD_ROOT%{_bindir}/* || :': han de ser eliminadas.

Todas estas cosas son para preparar los ficheros y dejarlos listos para ser empaquetados.

%clean

La intención de esta línea es limpiar el árbol de directorios de construcción $RPM_BUILD_ROOT.

rm -rf $RPM_BUILD_ROOT

Aquí es donde termina el trabajo.

[editar] Sección Files

%files 

Ésta sección consiste en una lista de ficheros que serán recogidos del árbol de simulación de directorios para el paquete. Vea el manual para las distintas opciones que no son usadas en éste ejemplo. (N. del T.: ésta es la frase original: "See the fine manual for the different options not being used in that simple example." No se indica cual es el manual)

La lista de ficheros debe ser escrita a mano en el fichero de especificaciones. Debe ser construida listando todos los ficheros creados por rpm en el árbol de directorios de construcción. Para hacer ésto, ejecute rpm -bi mypackage.spec para detener el proceso de construcción inmediatamente tras el proceso simulado de instalación. Entonces, mire en el directorio de simulación de instalación, en nuestro caso ~/rpm/tmp/gif2png-buildroot, para ver qué ficheros quiere añadir al paquete (la mayoría de las veces, serán todos los ficheros).

Tome nota de que nunca debería usar find para construir una lista de ficheros para incluir, sino explicitamente listar todos los ficheros (ésto mostrará errores en nuevas versiones). Las únicas excepciones son para casos de internacionalización para los cuales usted debería usar la macro %find_lang %{name} en la sección %install y reemplazar %files con %files -f %{name}.lang (vea Apéndice B). (N. del T.: Pendiente de revisar. Original: Note that you should never use find to build a list of files to include but explicitly list all files (this will show up bugs in new versions). The only exceptions is for locales for which you should use %find_lang %{name} in the %install section and replace %files by %files -f %{name}.lang (see Appendix B).

Nota sobre la estructura de directorios: Los ficheros que han de ser instalados por su paquete "deberían" seguir las recomendaciones FHS

%defattr(0755,root,root)

Ésta etiqueta define los atributos que se aplicarán a cada fichero que se copie en el sistema del usuario. Los cuatro (¿cuatro?) argumentos dados significan:

• -: todos los atributos de los ficheros regulares permanecen sin cambios,
• root: el propietario del fichero es root,
• root: el grupo del fichero es root,
• 0755: los atributos aplicados a todos los directorios que genere éste paquete son 0755 ( rwxr-xr-x ).

%doc README NEWS COPYING AUTHORS

La etiqueta especial %doc designa ficheros que forman parte de la documentación del paquete. Dichos ficheros (en el ejemplo) se ubicarán en /usr/share/doc/gif2png-2.0.1/. Este directorio se creará automáticamente. Los ficheros especificados en %doc son relativos a su directorio fuente descomprimido en BUILD.

%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*

Se recomienda listar aquí cada fichero man o info por separado.

Puede usted extrañarse del porqué se ha usado gif2png.1* en vez de gif2png.1.bz2. Esto se hace para conservar la compatibilidad con otros sistemas que pueden usar compresión gzip en lugar de la compresión bzip de Mandriva. Si descubre tales referencias a compresión bz2 en el fichero de especificaciones, cambielas a un comodín (wildcard). La mayoría de veces usted puede incluso usar %{_mandir}/man1/*; ésto tomará todos los ficheros que pueda encontrar.

%{_bindir}/gif2png
%{_bindir}/web2png

Como puede ver, usted tiene macros para cada tipo de ruta que necesite. Aquí aparecen las más útiles (para ver todas, mire en el fichero /usr/lib/rpm/macros): %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Para juegos, use %{_gamesbindir} y %{_gamesdatadir} .

[editar] Sección Changelog (registro de cambios)

%changelog 

Ésta sección es para seguir la pista de los diversos cambios hechos al paquete. A cada nueva construcción que cambie la 'release' del paquete debe corresponder tambien un párrafo en ésta sección como un incremento del número de 'release' (si no del número de versión). La estructura de éstos párrafos se debe respetar como sigue:

* Mon Nov 02 1999 Camille Begnis <[email protected]> 2.0.1-1mdk 

• La primera línea del párrafo comienza con * y, en orden, cada uno de los siguientes campos separado por un espacio:
• tres letras para el día de la semana,
• tres letras para el mes,
• dos números para el día del mes,
• cuatro números para el año,
• el nombre del empaquetador,
• el primer apellido del empaquetador,
• dirección de correo electrónico del empaquetador, entre los símbolos <>.
• versión y lanzamiento de las actuales modificaciones.

- Upgraded to 2.0.1

Entonces continúa con una línea por cada modificación aplicada al paquete, comenzando con un '-'.

He aquí algunos ejemplos:

- spec file stolen from korganizer. 
- last snapshot before release 
- Mandriva adaptations. 
- Fix bug in /etc/zsh use USERNAME instead of USER. 
- Remove petit bouchon which annoys other players. 
- Improve /etc/z* to source the /etc/profile.d/ files. 
- fix typo in examples directory name 
- fixed QT libs version requirements 
- add patch to handle Earl Grey tea 

Fíjese en que, de forma predeterminada, sólo se conservarán en la relación las modificaciones hechas durante el período de hasta un (1) año. Para cambiar éste comportamiento, modifique el valor de %_changelog_truncate.

[editar] La construcción

Nuestro fichero de especificaciones está finalmente completo. Respire profundamente, sientese, cruce los dedos y escriba rpm -ba mypackage.spec.

Puede también añadir la opción --clean, que limpia el directorio BUILD tras finalizar la construcción del paquete. Ésto es útil si tiene poco espacio disponible en disco.

Hay entonces dos posibilidades de resultado para ésta última línea del proceso:

• 0.01% probabilidades: + exit 0
• 99.99% probabilidades de otros casos.

¿Está usted en el segundo caso?. Felicidades, ha pasado el test, no es usted un alienígena.

A partir de aquí, le deseamos buena suerte. Eche un vistazo a las opciones de construcción con man rpm para depurar su trabajo, mire en ficheros de especificaciones de otras personas, etc...

Hay una forma muy limpia para construir paquetes: use rpm -bs --rmspec --rmsource (para quitar todo rastro de la construcción original) y entonces ejecute rpm --rebuild.

[editar] Optimice la construcción

Cuando usted lance el comando para construir su paquete, verá mensajes como "foo-devel is necessary for foo2" ("foo-devel es necesario para foo2").

Ésto significa que necesita informacion de otros paquetes usados para el desarrollo (usualmente, ficheros llamados foo.h). Si no los tiene, la compilación se detendrá, o ciertas características quedarán deshabilitadas en su paquete.

El sitio donde se construyen todos los paquetes oficiales de Mandriva (cluster de construcción en Mandriva) tiene preinstalados muchos de éstos paquetes de desarrollo. Si uno es necesario, y no está declarado en el fichero SPEC, aún así el paquete será construido en el cluster. Funcionará, pero la falta de ésta información evita que se pueda construir en máquinas que carecen del paquete de desarrollo, dificultando la depuración/actualización.

Mire en el sitio web del paquete, tendría que dar información sobre los componentes necesarios (aunque no siempre).

Una idea para cazar estas "necesidades para la construcción no encontradas" es empezar a empaquetar con sólo los paquetes básicos de desarrollo:

• glibc-devel
• libncurses5-devel
• libstdc++6-devel

Tras éstos, instale sólo los paquetes de desarrollo relativos que son solicitados por el comando de construcción de rpm.

Cuando lance la construcción, busque mensajes del tipo "checking for...".

Si ve alguna cosa como "checking for foo... foo.h not found", significa que una cabecera necesaria no ha sido encontrada en su sistema. Busque el paquete de desarrollo que contiene "foo.h", pero sea cuidadoso: puede encontrar más de un paquete que contenga lo que usted busca. Así que escoja el paquete más obvio. No escoja un paquete relacionado con redes de comunicaciones cuando usted está construyendo una aplicación relacionada con sonido (por ejemplo).

Entonces, instálelo en su sistema, y no olvide añadir su nombre en la sección BuildRequires en su fichero SPEC.

Las cabeceras que faltan se pueden encontrar durante la compilación misma. Si se detiene, revise otros archivos foo.h y aplique la misma receta.

[editar] Probar un RPM

Debería revisar las páginas de Bugzilla para más información acerca de éste asunto.

[editar] Pruebas básicas

Los primeros pasos a seguir son:

• ¿Los rpms son creados en los directorios correspondientes con los nombres correctos? (dentro de ~/rpm/SRPMS/ y ~/rpm/RPMS/i586/)
• ¿La información obtenida por el comando rpm -qlivp --changelog mipaquete.(src.)rpm es correcta?

[editar] Hilando (linting) el paquete

Lo siguiente que debe usar es rpmlint, que efectuará diversas pruebas sobre algunas cosas del paquete. Escriba rpmlint mipaquete.<arquitectura>.rpm y obtendrá un informe sobre el paquete especificado. Para más precisión, añada el parámetro -i. Debería usted revisar el rpm y el src.rpm. Se puede encontrar más información sobre los errores en Problemas de empaquetado (en inglés)

[editar] Prueba de instalación

En una máquina cualquiera - pero preferiblemente otra diferente de la usada para la compilación - haga una actualización o una instalación, y entonces revise:

• ¿Se crean los ficheros esperados en los directorios previstos, y con los derechos y propietarios adecuados?
• ¿Son efectivas las modificaciones de la instalación original (si hubiera)?
• ¿Los programas binarios y la documentación son accesibles para los usuarios que van a trabajar con ellos?

Los perfeccionistas intentarían varias instalaciones y desinstalaciones para verificar si todas las características previstas se han implementado correctamente, por ejemplo, probar sin tener instalados los paquetes requeridos.

Si los paquetes pasan todas estas pruebas con éxito, prácticamente ya lo habrá conseguido, y debería proceder con el último paso de proceso: emitir el paquete.

[editar] ¿Algo va mal?

Bien, parece que ha leído este manual, lo cual es un buen comienzo. Si no puede encontrar directamente la respuesta aquí, debería probar con el siguiente orden:

[editar] Para problemas generales de RPM:

1. El Cómo hacer RPM oficial (instalado en su sistema junto al programa rpm).
2. El libro "Maximum RPM" creado por Red Hat, que está disponible en Maximum RPM
3. Hacer una pregunta en la lista de correos rpm-list, a la que debería haberse suscrito hace tiempo (concretamente, al empezar a leer éstas páginas :D).

[editar] Para problemas específicos de RPM Mandriva:

Pregunte la cuestión en Mandriva Quality Assurance, <[email protected]>.

Si tiene la impresión de que la información que encuentre es útil para otros, en lo que se refiere al alcance de éste manual, sientase libre de hacer llegar su propuesta al encargado de mantenimiento de éste documento.

[editar] Sobre los scripts Pre- y Post-instalación

[editar] Nociones básicas

El paquete RPM es de hecho algo más que un simple archivo que contiene ficheros que serán ubicados en directorios específicos en los sistemas de los clientes.

El sistema ofrece al programador una gran posibilidad: scripts que se ejecuten antes y/o despues de la instalación/desinstalación. Permiten al encargado del paquete escribir una parte de código que será ejecutado en la máquina cliente cuando se instala o borra un paquete.

Estos scripts se crean con cualquier comando válido para 'sh'. Hay cuatro tipos:

Hay ciertas precauciones que deberá tener en cuenta sobre éstos scripts. Primero, cada uno no puede ser mayor de 8192 bytes y, segundo, no deberían ser interactivos. Cualquier cosa que necesite una respuesta del usuario está mal, y ésto romperá procedimientos no interactivos de instalación de RPM.

• %pre - Este script se ejecuta justo ANTES de que el paquete se INSTALE en el sistema.
• %post - Este script se ejecuta justo DESPUES de que el paquete se INSTALE en el sistema.
• %preun - Este script se ejecuta justo ANTES de que el paquete se DESINSTALE del sistema.
• %postun - Este script se ejecuta justo DESPUES de que el paquete se DESINSTALE del sistema.

El alcance de tales scripts puede ser enorme, y se deben diseñar con gran cuidado para no dañar el sistema sobre el que se operará. Uno ha de recordar que éstos scripts se ejecutarán como root... Corresponden a las tareas que un administrador de sistemas debería efectuar cuando se instala un nuevo programa en un sistema. Por ejemplo:

• Añadir un trabajo en cron para que funcione a intervalos determinados de tiempo
• Ejecutar chkconfig para que funcione como un servicio desde el arranque del sistema
• ...

[editar] Tratando con actualizaciones

El hecho de que un paquete pueda ser actualizado, y no simplemente instalado o desinstalado, hace la cosa aún un poco más complicada... El problema es que el script %postun de la actualización se ejecuta tras el script %post de la versión antigua. Así que todas las cosas del script %post se pierden...

A menudo es útil asegurarse de que una acción sucede sólo durante la instalación, y no durante la actualización. Lo mismo con una acción que sólo sucede durante una desinstalación y no durante una actualización. El mecanismo de RPM para tratar con ésto es el argumento que se le facilita de forma predeterminada a los scripts %pre, %preun, %post y %postun.

Éste argumento indica el número de instancias de éste RPM que se instalarán en la máquina cuando se haya completado el script en ejecución. Por ejemplo, si se instala un paquete nuevo, se facilitará 0 a %pre y 1 a %post. Cuando un paquete se actualiza, se especificará 1 a %pre del nuevo RPM, 2 a %post del nuevo RPM, 2 a %preun del paquete viejo y 1 a %postun del paquete viejo.

Tabla A-1. Valor del parámetro facilitado a los scripts pre y post

Parametro \ Script	%pre	%post	%preun	%postun
Para una instalación inicial	1	1	N/C	N/C
Para una actualización	2	2	1	1
Para una desinstalación	N/C	N/C	0	0

Ésto debería permitir al programador distinguir entre las distintas situaciones de sus scripts en función de la operación: instalación o actualización

• Para scripts de instalación ( %post, %pre ) verifique si $1 es igual a "1", lo que indicaría que es la primera instalación, no una actualización.
• Para scripts de desinstalación ( %postun, %preun ) verifique si $1 es igual a "0". Si es cierto, se trata de una desinstalación total; si no, o bien es una actualización o una reinstalación forzada del paquete (install --force).

Para verificar éste argumento se emplea la siguiente instrucción 'if':

%postun
if [ $1 = 0 ]; then
    // Hacer cosas específicas para desinstalaciones
fi
if [ $1 = 1 ]; then
    // Hacer cosas específicas para actualizaciones
fi

Una simple prueba es suficiente para ejecutar la acción correcta en el momento adecuado.

[editar] Más macros

Cuando se construyen RPM's para Mandriva Linux, se dispone de más macros que simplifican el fichero de especificaciones.

• Manejando las páginas de información. Un ejemplo es el mejor maestro:

%post
%''install''info %{name}.info

%preun
%''remove''install_info %{name}.info

• El sistema de menús. A partir de MandrivaLinux 2007.0 se usa el sistema de menú XDG, reemplazando el antiguo sistema de menú Debian.

%post
%{update_menus}

%postun
%{clean_menus}

• Manejando con limpieza la internacionalización. La mejor forma es no entrar a mano los archivos .mo que están usualmente en /usr/share/locale/.., sino usar una macro especial en la sección %install, que rellenará un fichero especial para éste propósito:

%find_lang %{name}

Entonces usted usará el fichero en la lista de ficheros:

%files -f %{name}.lang

• Macros de construcción: Las macros de construcción %configure y %makeinstall son bastante grandes hoy en día. Especifican el prefijo, pero también cada directorio común (como bindir, datadir, y otros); en circunstancias normales, trabajan sin problemas sobre paquetes de pequeño y mediano tamaño, pero para el resto siempre es necesaria alguna atención especial. La macro %make ejecuta el comando 'make' con la opción -j<num> apropiada para escalarse bien al trabajar en sistemas multiprocesador. Si necesita invocar manualmente el script ./configure, recuerde: NUNCA preestablezca la arquitectura; la macro %{targetplatform} existe para ese propósito (o incluso %{targetcpu} , si fuese necesario).
• Construyendo servidores. Para construir servidores más seguros especificamos una macro especial , %serverbuild, para usar antes de que ocurra la construcción real. Esto permite indicadores de optimización más seguros. La sección %build tendrá a menudo un aspecto parecido a éste:

%build
%serverbuild
%configure
%make

• Macros initscript. Cuando usted instala un paquete que lleva su propio initscript (los ficheros para el directorio /etc/init.d, normalmente servicios), éste necesita ser añadido con una llamada que se parece a chkconfig --add .., pero no en el caso de actualizaciones, y necesita ser reiniciado si está en funcionamiento cuando se hace la actualización; cuando se desinstala, deben hacerse cosas similares (opuestas); disponemos de macros específicas que hacen todo esto sin fallos:

%post
%''post''service <initscript-name>

%preun
%''preun''service <initscript-name>

• Manejo de ficheros fantasma. A menudo sucede con los juegos, algunas veces los paquetes usan un fichero variable que podría incluso no estar presente. Aquí es donde los ficheros fantasma son útiles. He aquí un ejemplo:

%install

(...)

mkdir -p $RPM_BUILD_ROOT/var/lib/games
touch $RPM_BUILD_ROOT/var/lib/games/methanescores

%post
%create_ghostfile /var/lib/games/powermanga.hi root games 664

(...)

%files
%attr(664, root, games) %ghost /var/lib/games/powermanga.hi

La macro %create_ghostfile se convertirá en lo siguiente:

if [ ! -f /var/lib/games/powermanga.hi ]; then 
  touch /var/lib/games/powermanga.hi
  chown root.games /var/lib/games/powermanga.hi
  chmod 664 /var/lib/games/powermanga.hi
fi 

• Asociación entre un fichero .desktop / mapeado de tipo MIME: el sistema de menú XDG permite establecer una asociación entre una aplicación y un tipo MIME en un fichero .desktop. La utilidad update-desktop-database debería ejecutarse si tal fichero .desktop es instalado / desinstalado en el sistema, usando macros tal como se muestra en el siguiente ejemplo:

%post
%update_desktop_database

%postun
%clean_desktop_database

• Base de datos de tipos MIME de Freedesktop.org: la base de datos usada para listar todos los tipos MIME disponibles, con patrones de extensión de fichero o de 'magic' debería ser actualizada como se muestra en el siguiente ejemplo:

%post
%update_mime_database

%postun
%clean_mime_database

• Caché de iconos: todos los paquetes que incluyen iconos en /usr/share/icons/hicolor (u otros directorios de temas de iconos de freedesktop, tales como /usr/share/icons/gnome o /usr/share/icons/crystalsvg) deben actualizar la caché de iconos, como se puede ver abajo (los iconos que se ubiquen en /usr/share/icons, /usr/share/icons/mini o /usr/share/icons/large no están incluidos en este requerimiento) :

...
%file
...
%{_icondir}/hicolor/*
%{_icondir}/crystalsvg/*
....

%post
%update_icon_cache hicolor
%update_icon_cache crystalsvg

%postun
%update_icon_cache hicolor
%update_icon_cache crystalsvg

• Registro de esquemas GConf : los esquemas GConf de GNOME deben ser instalados / desinstalados usando las siguientes macros:

...
# each schema key here corresponds to a file named /etc/gconf/schemas/<key>.schemas
%define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus

%post
%post_install_gconf_schemas %{schemas}

%preun
%preun_uninstall_gconf_schemas %{schemas}

• Actualizacion de la base de datos Scrollkeeper: cuando se instala un .omf, la base de datos scrollkeeper (usada para indexar los libros de documentación) debería ser actualizada como se muestra:

...
%post
%update_scrollkeeper

%postun
%clean_scrollkeeper

[editar] Interacción con urpmi y rpmdrake

A veces es necesario avisar al usuario acerca de algunas atenciones particulares que deben ser tenidas en cuenta cuando se actualiza o instala una versión específica de un paquete. rpmdrake-2.1.3-11mdk y superiores soportan ésta necesidad: busca en rpms ficheros de texto llamados README.install.urpmi, README.update.urpmi o README.urpmi, y los muestra.

El fichero README.install.urpmi se muestra sólo en instalaciones de paquetes; README.update.urpmi sólo en actualizaciones; README.urpmi es mostrado en ambos casos.

[editar] Grupos de Mandriva Linux

Se puede encontrar la lista de grupos de programas en grupos RPM

[editar] Licencias válidas para Mandriva Linux

Por favor, consulte Licencias Mandriva

[editar] Algunos enlaces

• Ark linux howto
• Artículo de IBM sobre la construcción de rpm
• Un artículo de la revista redhat sobre la construcción de rpm
• Tutorial Pdf sobre la construcción de rpm, escrito por GuruLabs
• Guía RPM en Red Hat

[editar] Otras fuentes interesantes de información sobre RPM en Mandriva

• Tutorial "Mandrake a la Gentoo" de Cybercfo

[editar] Glosario

• archivo - Durante la traducción, he tratado de referirme como archivo a un fichero empaquetado que contiene otros ficheros, o sea, los archivo.tar.gz, archivo.bzip, etc.
• cvs - Sistema de control de versiones. Guarda la historia de cambios de un elemento.
• fichero - Elemento individual de un directorio que contiene texto (ya sea descripciones, código fuente, configuraciones, scripts,...) o código binario (programa, icono,...).
• lanzamiento - Creo que es una buena traducción de la palabra inglesa release, mejor que subversión, que podría ser empleada en otros contextos con un significado diferente...
• magic - Algunos tipos de fichero son definidos no por su extensión, sino por un patrón especial de bytes que están en ciertas posiciones dentro del propio fichero. Hablando libremente, a estos patrones se les llaman 'magic numbers' o números mágicos.Wikipedia
• parche - Fichero de código fuente que modifica una parte del código fuente de un programa, ya sea para corregirlo o para añadir una funcionalidad. Mientras no está definitivamente integrado en el fichero de código fuente del programa, se suele aplicar a éste código fuente con el comando patch.
• vanilla - En inglés, vainilla. Dado que, por defecto, en EEUU un helado del que no se especifica el sabor se considera 'de vainilla', se aplica ésta comparación a otras cosas. En el caso de la informática (y no sabría decir si específicamente a Unix) se refiere a la versión estándar, sin personalizar, de un programa. Puede que ésto sea influencia de la costumbre de llamar 'sabores' (flavors) a distintas versiones de Unix.fuente