Sie sind auf Seite 1von 13

Formato del archivo «spec»

por Lucas Vieites

documento describe el formato de los archivos de

especificaciones «.spec» necesarios para la creación de paquetes rpm

utilizados para la distribución de software en sistemas Linux.

Este

Índice de contenido 1 Introducción 3 2 Comentarios 3 3 Tags o etiquetas 3 3.1

Índice de contenido

1 Introducción

3

2 Comentarios

3

3 Tags o etiquetas

3

3.1 Etiquetas relativas al nombre del paquete

4

3.1.1 Etiqueta name

4

3.1.2 Etiqueta version

4

3.1.3 Etiqueta release

4

3.2 Etiquetas descriptivas

4

3.2.1 Etiqueta %description

4

3.2.2 Etiqueta summary

5

3.2.3 Etiqueta license

5

3.2.4 Etiqueta vendor

5

3.2.5 Etiqueta url

5

3.2.6 Etiqueta group

5

3.2.7 Etiqueta packager

5

3.3 Etiquetas de dependencias

6

3.3.1 Etiqueta provides

6

3.3.2 Etiqueta requires

6

3.3.3 Etiqueta conflicts

6

3.4 Ejemplos

6

4 Scripts, la bestia de carga de RPM

7

4.1 Scripts de compilación

7

4.1.1 Script %prep

8

4.1.2 Script %build

8

4.1.3 Script %install

8

4.2 Scripts de instalación y eliminación

8

4.2.1 Script %pre

8

4.2.2 Script %post

9

4.2.3 Script %preun

9

4.2.4 Script %postun

9

5 La lista de archivos %files

9

6 Directivas para la lista %files

9

6.1 Directivas relacionadas con archivos

9

6.1.1 Directiva %doc

10

6.1.2 Directiva %config

10

6.1.3 Directiva %attr

10

6.2 Directivas relacionadas con directorios

11

6.2.1 Directiva %docdir

11

6.2.2 Directiva %dir

11

7 Directiva %package

11

8 Condicionales

11

8.1 Condicional %ifarch

11

8.2 Condicional %ifnarch

12

8.3 Condicional %ifos

12

8.4 Condicional %ifnos

12

8.5 Condicional %else

12

8.6 Condicional %endif

12

9

Ejemplo de archivo spec

13

10 Bibliografía

13

Sección: 1 Introducción

1 Introducción

La creación de paquetes rpm para la distribución de software en sistemas Linux se realiza mediante el comando «rpmbuild». Éste utiliza un archivo de configuración en el que se indican las acciones que debe realizar el paquete para instalar el software en cuestión. Este archivo de especificaciones (en inglés «specifications file») es el archivo spec; un archivo de texto que se puede modificar con un editor de texto corriente (vi, gedit, kate, etc.).

Un archivo spec se compone de varios tipos de entradas de las cuales algunas son de uso obligatorio, y otras son opcionales según lo requiera el tipo de paquete que queramos generar. Los diferentes tipos de entrada son:

Comentarios: Anotaciones aclaratorias, ignoradas por RPM

Tags o etiquetas: Definición de datos.

Scripts: Contienen comandos que se deben ejecutar en momentos puntuales.

Macros: Permiten la ejecución de varios comandos con facilidad

La lista de archivos %files: Una lista de archivos que se incluirán en el paquete

Directivas: Utilizadas en la lista %files para indicar a RPM que trate a ciertos archivos de un modo específico.

Condicionales: Permiten el preprocesamiento del archivo spec según el tipo de arquitectura o sistema operativo.

2 Comentarios

Los comentarios son un modo de hacer que RPM ignore una línea del archivo. El contenido de los comentarios depende completamente de la persona que escriba el archivo y normalmente se utilizan para realizar anotaciones que mejoren la comprensión de las acciones indicadas.

Para crear un comentario, simplemente escriba el signo almohadilla («#») al inicio de la línea. Cualquier texto entre este signo y el fin de línea será ignorado por RPM.

# Esto es el archivo spec para el programa talycual

Los comentarios se pueden colocar en cualquier lugar del archivo spec.

3 Tags o etiquetas

Las etiquetas se utilizan para marcar un conjunto de datos. Estos datos se agrupan al inicio del archivo spec en una sección denominada preámbulo. La etiquetas se separan de sus datos mediante dos puntos «:» y no son sensibles a la capitalización, es decir; se pueden escribir en letras mayúsculas, minúsculas o una mezcla de ambas, por ejemplo:

Name:

Version: 1.0.0 Release: 1 Summary: Un programa de prueba

talycual

Es también notable que el espaciado entre la etiqueta y sus datos es irrelevante. Teniendo en cuenta estas reglas podemos decir que el siguiente ejemplo tiene el mismo resultado que el anterior:

NAME:

talycual

version:1.0.0

ReLEasE:

1

suMMarY:

Un programa de prueba

A continuación describiremos diferentes tipos de etiquetas.

Tags o etiquetas

3.1 Etiquetas relativas al nombre del paquete

3.1.1 Etiqueta name

La etiqueta name se utiliza para indicar el nombre del software que se va a empaquetar. El nombre que se

indique en esta etiqueta debe ser idéntico al nombre del paquete.

3.1.2 Etiqueta version

La etiqueta version define la versión del software que se va a empaquetar. El número de versión indicado

debe ser lo más parecido posible al formato original de la versión del software. En la mayoría de los casos, esto no es problemático, sin embargo hay una restricción; no se puede utilizar el carácter «guión» («-») en la versión. Los espacios también son problemáticos, ya que RPM ignorará todo lo que haya después del primer espacio.

NOTA: Cíñase al uso de caracteres alfanuméricos y puntos y nunca tendrá que preocuparse.

3.1.3 Etiqueta release

Se puede pensar en la etiqueta release como en la versión del paquete. El número de release normalmente

es un número entero. Por ejemplo: cuando se empaqueta una versión en concreto de un software por primera vez, el número de release deberá ser 1. Si es necesario volver a empaquetar esa misma versión del software el número de release se deberá incrementar. Cuando aparezca una nueva versión del software, el número de release se deberá reiniciar a 1.

3.2 Etiquetas descriptivas

Estas etiquetas proporcionan información a quien desee saber más acerca del paquete y acerca de quién lo ha

producido. Son parte del paquete y se mostrarán mediante el comando rpm -qi nombre_paquete.

3.2.1 Etiqueta %description

Mediante esta etiqueta se proporciona una descripción en profundidad del software empaquetado. Esta descripción puede ser de varias líneas que contengan la suficiente información para que un usuario desinformado comprenda qué hace el software.

La etiqueta %description es distinta de las demás etiquetas de preámbulo. En primer lugar va precedida del

símbolo de porcentaje («%»). La otra diferencia es que los datos que contiene pueden abarcar varias líneas y además se pueden formatear de una forma muy precaria. Si una línea comienza por un espacio, RPM la mostrará tal cual. Si no comienza con un espacio, se asumirá que es parte de un párrafo y se formateará como tal. Hasta es posible mezclar líneas formateadas y sin formatear:

%description Es un pájaro. Es un avión. Es un software excepcional que no tiene comparación. Al usar la frecuencia de bytes del flujo integral recibido, realiza la transformación especular inversa al 20% de la muestra. De esta forma se genera una calidad de defracción inédita.

El ejemplo anterior no contiene información explícita de formato. RPM formateará el texto como un párrafo único, partiendo las líneas según sea necesario.

Sección: 3.2 Etiquetas descriptivas

El siguiente ejemplo es distinto:

%description Es un pájaro. Es un avión. Es un software excepcional que no tiene comparación. Al usar la frecuencia de bytes del flujo integral recibido, realiza la transformación especular inversa al 20% de la muestra. De esta forma se genera una calidad de defracción inédita.

Las tres primeras líneas se mostrarán tal cual, el resto del texto se formateará como un solo párrafo.

3.2.2 Etiqueta summary

Esta etiqueta se utiliza para proporcionar una descripción de una sola línea del software empaquetado. A

diferencia de %description, el contenido de summary está restringido a una sola línea.

3.2.3 Etiqueta license

En versiones más antiguas de RPM, esta etiqueta se llamaba copyright. Se utiliza para indicar qué tipo de licencia rige el uso y distribución del software empaquetado y qué derechos tiene el usuario. En muchos casos el contenido de esta etiqueta será simplemente el siguiente:

License: GPL

3.2.4 Etiqueta vendor

La etiqueta vendor se utiliza para indicar el nombre de la entidad responsable de empaquetar el software. Normalmente es el nombre de una organización o empresa:

Vendor: PSA Peugeot-Citroën

3.2.5 Etiqueta url

Indica una dirección on-line en la que se puede obtener información adicional acerca del software.

3.2.6 Etiqueta group

La etiqueta group se utiliza para agrupar paquetes según el tipo de funcionalidad que proporcionan. El formato

utilizado es similar a una ruta de un sistema de archivos y tiene una función similar. Por ejemplo, un paquete que contenga un editor de textos podría tener el siguiente grupo:

Group: Applications/Editors

Esta información se utiliza principalmente en programas con interfaz gráfica para mostrar los paquetes de forma jerárquica. Para que la ordenación por grupos sea lo más efectiva posible es necesario que todos los constructores de paquetes sean consistentes en el uso de los nombres de grupos. Las distribuciones de Suse Linux se apoyan en la guía de empaquetado («SUSE Package Conventions»), en cuyo segundo capítulo se encuentra un listado completo de los grupos utilizados en sus paquetes.

3.2.7 Etiqueta packager

La etiqueta packager contiene el nombre y la información de contacto de la persona o personas que han

construido el paquete.

Tags o etiquetas

3.3 Etiquetas de dependencias

3.3.1 Etiqueta provides

La etiqueta provides se utiliza para indicar el nombre de un paquete virtual que el software

empaquetado pone disponible cuando sea instalado. Normalmente se utiliza esta etiqueta cuando diferentes paquetes proporcionan servicios equivalentes. Por ejemplo, cualquier paquete que permita a un usuario editar un archivo de texto podría proporcionar el paquete virtual text-editor, el software instalado puede ser cualquier editor («vi», «gedit», «kate», etc.). Otro paquete que depende de que haya un editor de textos instalado podrá requerir que esté instalado el paquete editor-textos para instalarse sin problemas.

Provides: text-editor

3.3.2 Etiqueta requires

La etiqueta requires se utiliza para alertar a RPM de que el paquete necesita que haya ciertos

requisitos disponibles para poder funcionar correctamente. Estos requisitos se refieren al nombre de otro paquete, o a un paquete virtual, proporcionado por uno o más paquetes que utilicen la etiqueta provides.

En la etiqueta requires se pueden utilizar operadores para la comparación de versiones y releases. Por

ejemplo, en la siguiente etiqueta se indica que el paquete necesita que esté instalada la versión «1.5.0» o superior del software «JRE».

Requires: jre >= 1.5.0

3.3.3 Etiqueta conflicts

La etiqueta conflicts es el complemento lógico de requires. Mientras que requires indica qué

software debe estar instalado para que el paquete funcione, conflicts indica qué software no puede estar instalado si queremos que este paquete funcione correctamente.

3.4 Ejemplos

A continuación algunos ejemplos de software con licencia privativa y GPL en la distribución Novell SLED 10 (esta información se obtiene con el comando «rpm -qi nombre_paquete »):

Sun Microsystems JRE

# rpm -qi jre Name Version Release

Install Date: jue 18 oct 2007 10:38:23 CEST Build Host: tiger-linux

: jre

: 1.5.0_11

: fcs

Relocations: /usr/java Vendor: Sun Microsystems, Inc. Build Date: vie 15 dic 2006 13:34:48 CET

Group

: Development/Tools

Source RPM: jre-1.5.0_11-fcs.src.rpm

Size

: 41275304

License: Sun Microsystems Binary Code License (BCL)

Signature

: (none)

Packager

: Java Software <jre-comments@java.sun.com>

URL

: http://java.sun.com/

Summary

: Java(TM) 2 Platform Standard Edition Runtime Environment

Description :

The Java 2 Platform Standard Edition Runtime Environment (JRE) contains everything necessary to run applets and applications designed for the Java platform. This includes the Java virtual machine, plus the Java platform classes and supporting files.

Sección: 3.4 Ejemplos

The JRE is freely redistributable, per the terms of the included license. Distribution: (none)

Adobe Reader

# rpm -qi acroread

Name

: acroread

Relocations: (not relocatable)

Version

: 7.0.9

Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany

Release

: 1.2

Build Date: vie 19 ene 2007 19:24:43 CET

Install Date: jue 18 oct 2007 10:37:01 CEST

Build Host: eisler.suse.de

Group

: Productivity/Publishing/PDF

Source RPM: acroread-7.0.9-1.2.nosrc.rpm

Size

: 115216999

License: Commercial (all types)

Signature

: DSA/SHA1, vie 19 ene 2007 19:29:21 CET, Key ID a84edae89c800aca

Packager

: http://bugs.opensuse.org

URL

: http://www.adobe.com/products/acrobat/readermain.html

Summary

: Adobe Reader for PDF Files

Description :

The Adobe Reader is proprietary binary-only software.

Normally the Adobe Reader is used to display PDF files on the screen.

For this purpose at least the minimum graphical system must be

installed (the packages that provide the RPM capability

[ ]

Kernel

# rpm -qi kernel-default

Name

: kernel-default

Relocations: (not relocatable)

Version

: 2.6.16.46

Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany

Release

: 0.14

Build Date: jue 14 jun 2007 01:14:18 CEST

Install Date: jue 18 oct 2007 12:29:57 CEST

Build Host: nepomuk.suse.de

Group

: System/Kernel

Source RPM: kernel-default-2.6.16.46-0.14.nosrc.rpm

Size

: 48749856

License: GNU General Public License (GPL)

Signature

: DSA/SHA1, jue 14 jun 2007 01:20:43 CEST, Key ID a84edae89c800aca

Packager

: http://bugs.opensuse.org

URL

: http://www.kernel.org/

Summary

: The Standard Kernel

Description :

The standard kernel.

Source Timestamp: 2007/05/17 14:00:09 UTC CVS Branch: SLES10_SP1_BRANCH Distribution: SUSE Linux Enterprise 10 (i586)

4 Scripts, la bestia de carga de RPM

Entre las partes más variables e interesantes del archivo spec se encuentran los scripts que RPM utiliza para controlar el proceso de construcción. Muchos archivos spec también utilizan scripts que realizan gran variedad de acciones durante la instalación o eliminación del paquete.

El inicio de cada script se marca con una palabra clave. Por ejemplo, la palabra %build marca el inicio del

script que RPM ejecutará al compilar el código del software que se empaquetará. En el sentido estricto de la palabra estas partes del archivo spec no son realmente scripts, es decir; no empiezan con la tradicional invocación de una shell. Sin embargo el contenido de cada sección de script se copia a un archivo y se ejecuta como un script de pleno derecho. Esto es parte de la potencia de RPM; todo lo que se puede hacer en un script lo puede hacer RPM.

4.1 Scripts de compilación

Los scripts utilizados por RPM durante la construcción de un paquete siguen los pasos conocidos por todos los

Scripts, la bestia de carga de RPM

desarrolladores de software:

 

Desempaquetar los fuentes

Compilar el software

Instalar el software

Limpieza

4.1.1

Script %prep

El script %prep es el primero que RPM ejecuta durante la construcción. Antes de ejecutar este script RPM ya ha

realizado una serie de comprobaciones preliminares, como por ejemplo si la etiqueta source apunta a archivos que

realmente existen. Justo antes de pasar el control al contenido del script %prep, RPM cambia de directorio al área de

construcción que, por defecto, es /usr/src/packages/. En este punto es responsabilidad del script:

Crear el directorio de compilación.

Desempaquetar los archivos de fuentes en el directorio de compilación.

Aplicar los parches al código, si es necesario.

Realizar cualquier otra acción necesaria para que los fuentes se encuentren en un estado «listo para compilar».

4.1.2 Script %build

El script %build toma el testigo de %prep para realizar la compilación del software. Normalmente consiste

simplemente del comando make, algún script de configuración y poco más.

4.1.3 Script %install

El entorno en el que se ejecuta el script %install es idéntico al que utilizan %prep y %build. Tal y como

implica su nombre, el objetivo de este script es instalar el software recién compilado. En la mayoría de los casos esto

simplemente significa ejecutar el comando make install o unos cuantos comandos que copien archivos y creen

directorios.

4.2 Scripts de instalación y eliminación

El otro tipo de script presentes en el archivo spec son aquellos que se utilizan solamente cuando el paquete se

instala o elimina del sistema (desinstala). Hay cuatro scripts, cada uno de los cuales se ejecutará en un momento

distinto de la vida del paquete:

Antes de la instalación

Después de la instalación

Antes de la desinstalación

Después de la desinstalación

4.2.1 Script %pre

El script %pre

se ejecuta justo antes de la instalación del paquete. Este script se utiliza en muy escasas

ocasiones (de hecho en la distribución SLED 10 solamente lo usan una escasa docena de paquetes).

Sección: 4.2 Scripts de instalación y eliminación

4.2.2 Script %post

El script %post se ejecuta justo después de la instalación del paquete. Una de las razones más comunes por la

que utilizarlo es ejecutar el comando ldconfig para actualizar la lista disponible de bibliotecas compartidas después de instalar una.

Si un paquete utiliza un script %post para realizar alguna función es común que también incluya un script

%postun que realiza las operaciones inversas del %post, después de eliminar el paquete.

4.2.3 Script %preun

Cualquier cosa que un paquete debe hacer antes de desaparecer del sistema lo debe hacer en el script

%preun. Por ejemplo, asegurarse de que cualquier servicio que hay iniciado esté detenido.

4.2.4 Script %postun

Después de que el paquete haya sido desinstalado se ejecuta el script %postun. Es la última oportunidad para

realizar una limpieza, por ejemplo; ejecutar ldconfig para eliminar bibliotecas compartidas de ld.so.cache.

5 La lista de archivos %files

La lista %files le indica a RPM qué archivos del entorno de compilación se deben empaquetar. La lista consta

de un archivo por línea y cada archivo puede ir precedido de una o más directivas. Estas directivas proporcionan información adicional acerca del archivo.

En el caso de que un paquete contenga una gran cantidad de archivos puede llegar a ser muy tedioso mantener

actualizada la lista %files. Para facilitar esta situación, si se indica la ruta de un directorio RPM empaquetará

automáticamente todos los archivos y subdirectorios contenidos en él de modo recursivo. El uso de comodines (al estilo shell) también está permitido.

6 Directivas para la lista %files

Las directivas utilizadas en la lista %files tienen los siguientes objetivos:

Identificar archivos de documentación y configuración.

Asegurar que un archivo posee los permisos y propietarios adecuados.

Controlar qué aspectos de un archivo se deben comprobar durante la verificación de un paquete.

Es posible indicar más de una directiva en una sola línea, separada por espacios, delante de uno o más nombres de archivo del siguiente modo:

%dir %defattr /ruta/al/archivo

6.1 Directivas relacionadas con archivos

A pesar de que RPM procesa archivos de diferente forma según su tipo no dispone de ningún mecanismo para determinar automáticamente el tipo de archivo con el que está tratando. Por eso es responsabilidad del constructor del

paquete marcar los archivos de la lista %files adecuadamente. Esto se hace mediante las directivas que se describen

más abajo. Tenga en cuenta que no todos los archivos deben ser marcados, de hecho solamente se utilizan estas

Directivas para la lista %files

directivas en casos muy concretos. En la mayoría de los paquetes la mayor parte de los archivos de la lista %files no

necesita ser marcado.

6.1.1 Directiva %doc

La directiva %doc precede a los archivos que son documentación. RPM mantiene información en su base de

datos acerca de los archivos de documentación para que un usuario pueda encontrarla fácilmente. Además, RPM puede crear un directorio especial para documentación durante la instalación y copiar archivos en él. Si se usa o no esta capacidad depende de cómo se especifica un archivo:

%doc LEEME %doc /usr/local/miprograma/LEEME

En el primer caso el archivo LEEME existe en el directorio superior del software durante la compilación y se

incluye en el paquete. Cuando se instala dicho paquete, RPM crea un directorio con el mismo nombre que el paquete (p.ej.: <programa>-<version>-<release>) en el directorio de documentación del sistema y copia dentro el archivo

LEEME. El directorio de documentación predeterminado del sistema se define en el archivo rpmrc mediante la entrada

defaultdocdir (véase Apéndice B del libro «Maximum RPM»)

En el segundo caso el archivo /usr/local/miprograma/LEEME se instaló en ese directorio durante la

compilación y está incluido en el paquete. Al íinstalar el paquete el archivo LEEME se copia en

/usr/local/miprograma/ y se marca en la base de datos RPM como documentación.

6.1.2 Directiva %config

La directiva %config se utiliza para marcar el archivo indicado como archivo de configuración. RPM realiza

procedimientos adicionales con los archivos de configuración durante la instalación o actualización. Esto es debido a la naturaleza de los archivos de configuración; a menudo son modificados durante la vida del software y esos cambios no se deben perder. En este caso solamente se puede indicar un solo nombre de archivo en cada línea que contenga la

directiva %config. Tenga también en cuenta que es necesario indicar la ruta completa del archivo:

%config /etc/mi_archivo.conf

6.1.3 Directiva %attr

Esta directiva proporciona el control sobre los atributos de los archivos:

Los permisos o «modo» del archivo

El ID de usuario del archivo

El ID de grupo del archivo

La directiva %attr tiene el siguiente formato:

%attr (<modo>, <usuario>, <grupo>) nombre_archivo

El modo se indica mediante el tradicional formato numérico, mientras que el usuario y el grupo se indican mediante una cadena de texto como, por ejemplo, «root»:

%attr (755, root, root) mi_archivo.conf

Si no es necesario indicar alguno de los atributos porque ya son correctos en el momento de la instalación, éstos se pueden sustituir por el carácter «guión».

%attr (755, -, root) mi_archivo.conf

Sección: 6.1 Directivas relacionadas con archivos

La principal razón para utilizar la directiva %attr es la de permitir a usuarios sin permisos root compilar paquetes.

6.2 Directivas relacionadas con directorios

6.2.1 Directiva %docdir

Esta directiva le indica a RPM que el directorio que le sucede contiene documentación. Solamente indica esta

circunstancia, por lo que igualmente es necesario añadir el directorio en la lista %files para que sea empaquetado.

%docdir /var/opt/miprograma/docs /var/opt/miprograma/docs/

En este ejemplo se incluirá todo el directorio /var/opt/miprograma/docs/ en el paquete y al consultar

los documentos contenidos en el paquete se mostrarán todos los archivos contenidos en él, aunque no hayamos usado

la directiva %doc ni hayamos incluido los archivos uno por uno en la lista %files:

# rpm -qlp miprograma-1.0-1.i586.rpm

/var/opt/miprograma/docs/LEEME.txt

/var/opt/miprograma/docs/manual.pdf

6.2.2 Directiva %dir

Ya se ha mencionado anteriormente que si se indica la ruta de un directorio en la lista %files, se empaquetará

todo su contenido, incluidos los subdirectorios. Aunque esta capacidad puede resultar útil, también puede causar

problemas innecesarios. Para evitar estos inconvenientes se utiliza la directiva %dir. Al añadir esta directiva a la línea

que contiene la ruta del directorio, RPM empaquetará solamente el directorio, sin tener en cuenta los archivos o subdirectorios que pueda contener.

7 Directiva %package

Mientras que todas las directivas comentadas hasta ahora se utilizan dentro de la lista %files, la directiva

%package es diferente; se utiliza para la creación de más de un paquete por archivo spec y puede aparecer en

cualquier lugar del éste. Puesto que la creación de subpaquetes no es del ámbito de este documento, solamente indicaremos el formato de esta directiva:

%package: nombre_del_paquete

8 Condicionales

En ocasiones surge la necesidad de compilar un paquete para varias arquitecturas diferentes. Cada una de estas arquitecturas puede requerir distintos archivos o scripts, por lo que la solución obvia sería la creación de diferentes archivos spec. Sin embargo esta solución plantea serios problemas de mantenimiento y evolución.

RPM proporciona para estos casos varias sentencias condicionales que a continuación resumiremos:

8.1 Condicional %ifarch

Se utiliza al inicio de una sección que es específica de una o varias arquitecturas. En el siguiente ejemplo el contenido del bloque condicional solamente se ejecutará si la arquitectura es Intel x86 o Sun SPARC

%ifarch i386 sparc

Condicionales

%endif

8.2 Condicional %ifnarch

Esta condicional es similar a la anterior pero en este caso la lógica es inversa. El contenido del bloque condicional se ejcutará si la arquitectura no coincide con las indicadas.

8.3 Condicional %ifos

La condicional %ifos se utiliza para controlar el proceso del archivo spec basado en el sistema operativo del

sistema de compilación.

%ifos linux

%endif

8.4 Condicional %ifnos

La condicional %ifnos es el complemento lógico de %ifos, es decir, si una línea comienza con la condicional

%ifnos irix, el contenido del bloque no se ejecutará si el sistema operativo de la máquina es Irix.

8.5 Condicional %else

La condicional %else se coloca entre una condicional de tipo %if y su correspondiente %endif. Se utiliza

para crear dos bloques de sentencias de los cuales solo uno se ejecutará de acuerdo con la condición indicada.

%ifarch alpha make RPM_OPT_FLAGS="$RPM_OPT_FLAGS -I *" %else make RPM_OPT_FLAGS="$RPM_OPT_FLAGS -I *" %endif

8.6 Condicional %endif

Un %endif se utiliza para finalizar un bloque condicional. Puede aparecer después de una condicional de tipo

%if o detrás de un %else.

Sección: 9 Ejemplo de archivo spec

9

Ejemplo de archivo spec

#

# Plantilla para la creación de archivos .spec

#

Name: nombre_paquete Version:

Release:

 

Summary:

Group:

License:

URL:

Vendor:

Packager:

Source:

Patch:

BuildRoot: %{_tmppath}/%{name}-root Provides:

Requires:

 

Conflicts:

%description

%prep

%setup -c 'nombre_paquete-%{version}'

%patch

 

%build

%install

%

cp

-a . "${RPM_BUILD_ROOT-/}"

%clean [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "$RPM_BUILD_ROOT"

%pre

 

%post

%preun

%postun

%files %defattr(-,root,root) %dir /usr/ %dir /usr/local/ %dir /usr/local/

%changelog * Thu Jul 19 2007 nombre del empaquetador - Version 0.0.1

10

Bibliografía

«Maximum RPM, Taking the RPM Package Manager to the Limit» Edward C. Bailey, Paul Nasrat, Matthias Saou, Ville Skyttä (http://www.rpm.org)