From Fedora Project Wiki
m (internal link cleaning)
 
(43 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= Configure su cuenta en su sistema =
+
{{autolang}}
  
Instalación de software necesario:
+
== Introducción ==
  
  # yum groupinstall "Development Tools"
+
Esta página describe detalladamente cómo crear un paquete RPM y en particular, cómo crear un archivo SPEC. A diferencia de otras guías RPM, esta página explica los detalles de Fedora con enlaces a los lineamientos específicos de Fedora. Dado que es mantenida a través de la Wiki de Fedora, es probable que esté más al día que otras guías. A pesar del enfoque en Fedora, la mayor parte de este documento se aplica a otras distribuciones basadas en RPM. Si está impaciente, puede comenzar por mirar el más breve [[How to create a GNU Hello RPM package|Cómo crear un paquete RPM GNU Hola]].
  # yum install rpmdevtools
 
  # yum install rpmlint
 
  
Una sugerencia es utilizar un usuario aparte para crear paquetes RPM en su sistema , de esa forma, si algo va terriblemente mal, podrá simplemente tirar al cesto de la basura todo el entorno y volver a empezar sin presión de perder datos personales en su directorio /home.
+
Tenga en cuenta que estos ''no'' son los lineamientos del paquete oficial de Fedora, que puede verse en los [[Packaging:Guidelines|Lineamientos de empaquetado]] y [[Packaging:NamingGuidelines|Lineamientos de nombrado de paquetes]]. Dicho esto, esta página debe ser compatible con ellos.
  
  # useradd makerpm
+
Si va a crear un paquete RPM para el repositorio de Fedora, siga el procedimiento para [[Join the package collection maintainers/es|unirse a los mantenedores de la colección de paquetes]].
  
Una vez ingresado al sistema con el usuario adecuado:
+
== Preparando su sistema ==
  
  # [makerpm@movix ~]$ rpmdev-setuptree
+
Antes de crear paquetes RPM en Fedora, necesita instalar algunas herramientas básicas de desarrollo y configurar la(s) cuenta(s) que va a utilizar:
 +
# yum install @development-tools
 +
# yum install fedora-packager
  
El programa "rpmdev-setuptree" creará el directorio "rpmbuild" en su directorio $HOME, En dicha estructura existen una serie de subdirectorios tales como SPECS y BUILD que usted utilizará para crear sus paquetes. El programa "rpmdev-setuptree" también crea el archivo "~/.rpmmacros" que provocará que rpm y rpmbuild lo utilicen cuando sea necesario.
+
Puede crear un usuario ficticio (dummy) específicamente para crear paquetes RPM por si el proceso de construcción sale mal no podrá destruir sus archivos o enviar sus claves privadas al mundo.
  
Una vez que ha configurado su cuenta, normalmente no habrá necesidad de volver a ejecutar estos pasos nuevamente.
+
{{admon/caution|Usted ''nunca'' debe crear los paquetes como usuario root.}}
  
= Fundamentos en la construcción de un RPM =
+
Crear un nuevo usuario con el nombre <code>makerpm</code>, agregar el usuario al grupo 'mock', establecer una contraseña e ingresar como usuario:
 +
# /usr/sbin/useradd makerpm
 +
# usermod -a -G mock makerpm
 +
# passwd makerpm
  
Para crear un paquete RPM usted necesitará crear un archivo de texto ".spec" que suministre la información acerca del software que será empaquetado. Luego usted podrá ejecutar el comando "rpmbuild" sobre dicho archivo spec lo que provocará ejecutar una serie de pasos para producir sus paquetes.
+
Una vez que ha iniciado la sesión como un usuario build/dummy, crear la estructura de directorios necesaria en su directorio home ejecutando:
 +
$ rpmdev-setuptree
  
Normalmente usted deberá colocar sus fuentes originales (prístinas), archivos tales como .tar.gz provistos por los desarrolladores originales, en "~/rpmbuild/SOURCES". Usted deberá colocar su archivo .spec en "~/rpmbuild/SPECS" y nombrarlo "''NOMBRE''.spec" donde ''NOMBRE'' es el nombre (vase) del paquete. Para crear todos los paquetes, tanto binario como fuente, usted deberá cambiarse al directorio "~/rpmbuild/SPECS" y ejecutar:
+
El programa <code>rpmdev-setuptree</code> creará el directorio <code>~/rpmbuild</code> y una serie de subdirectorios (por ejemplo <code>SPECS</code> y <code>BUILD</code>), que va a usar para crear sus paquetes. También se crea el archivo <code>~/.rpmmacros</code>, que puede utilizarse para configurar diversas opciones.
  
rpmbuild -ba ''NOMBRE''.spec
+
[[Packaging:Guidelines#Timestamps|Los lineamientos de empaquetado recomiendan preservar los datos del archivo]]; usted puede hacer esto automáticamente si usa <code>wget</code> o <code>curl</code> para obtener los archivos fuentes. Si utiliza <code>wget</code> para obtener los archivos fuentes, añada el texto «<code>timestamping = on</code>» a <code>~/.wgetrc</code>. Si usa <code>curl</code>, agregue el texto «<code>-R</code>» a <code>~/.curlrc</code>.
  
rpmbuild invocado de esta manera leerá el archivo .spec e intentará ejecutar las siguientes, en ese orden (los nombres que comienzan con % so macros predefinidos y que luego se comentarán, los directorios sobre los que se actúa son listados):
+
Normalmente, no necesitará volver a realizar estos pasos.
{|
+
 
!Etapa !! Lee !! Escribe !! Acción
+
== Los fundamentos de la construcción de paquetes RPM ==
 +
 
 +
Para crear un paquete RPM, necesitará crear un archivo de texto «<code>.spec</code>» que suministre la información acerca del software que será empaquetado. Luego podrá ejecutar el comando <code>rpmbuild</code> sobre dicho archivo SPEC, lo que provocará ejecutar una serie de pasos para producir sus paquetes.
 +
 
 +
Normalmente, deberá colocar sus fuentes originales (prístina), archivos tales como <code>.tar.gz</code> provistos por los desarrolladores originales, en el directorio <code>~/rpmbuild/SOURCES</code>. deberá colocar su archivo <code>.spec</code> en el directorio <code>~/rpmbuild/SPECS</code> y asignarle el nombre «''NOMBRE''.spec», donde ''NOMBRE'' es el nombre base del paquete. Para crear ambos paquetes, tanto el binario como el fuente, cambie al directorio <code>~/rpmbuild/SPECS</code> y ejecute:
 +
$ rpmbuild -ba ''NOMBRE''.spec
 +
 
 +
Cuando <code>rpmbuild</code> es invocado de esta manera, leerá el archivo <code>.spec</code> y recorrerá en orden las etapas listadas a continuación. Los nombres que comienzan con <code>%</code> son macros predefinidas (vea la siguiente tabla).
 +
 
 +
{|border="1" cellspacing="0"
 +
! Etapa !! Lee !! Escribe !! Acción
 
|-
 
|-
|%prep ||%_sourcedir||%_builddir||Se leen la fuentes y parche en el directorio fuente %_sourcedir (usualmente ~/rpmbuild/SOURCES). Se desempaca las fuentes al subdirectorio bajo el directorio de construcción %_builddir (usualmente ~/rpmbuild/BUILD/) y se aplican los parches.
+
|<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Esta lee los archivos fuentes y parches en el directorio de fuentes <code>%_sourcedir</code>. Se desempaquetan los archivos fuentes al subdirectorio dentro del directorio de construcción <code>%_builddir</code> y se aplican los parches.
 
|-
 
|-
|%build ||%_builddir||%_builddir||Se compilan los fuentes localizados en el directorio de construcción %_builddir (usualmente ~/rpmbuild/BUILD/). Esto se hace comunmente implementando alguna variación de "./configure ; make".
+
|<code>%build</code>||<code>%_builddir</code>||<code>%_builddir</code>||Esta compila los archivos dentro del directorio de construcción <code>%_builddir</code>. Esto se hace a menudo implementando alguna variación de «<code>./configure && make</code>».
 
|-
 
|-
|%check||%_builddir||%_builddir||Verifica que el software funciona correctamente. Esto es usualmente implementado ejecutando alguna variación de "make test". Muchos paquetes no implementan esta etapa.
+
|<code>%check</code>||<code>%_builddir</code>||<code>%_builddir</code>||Verifica que el software funciona correctamente. Esto es usualmente implementado ejecutando alguna variación de «<code>make test</code>». Muchos paquetes no implementan esta etapa.
 
|-
 
|-
|%install||%_builddir|| %_buildrootdir||Se leen los archivos en el directorio de construcción %_builddir (usualmente ~/rpmbuild/BUILD/) y se escribe en el directorio raíz de construcción %_buildrootdir (usualmente ~/rpmbuild/BUILDROOT). Los archivos que son escritos son los que se suponen que sean instalados cuando el paquete binario sea instalado por el usuario final. Esté al tanto de la terminología algo extraña, el "directorio raíz de construcción" no es lo mismo que el "directorio de construcción". Esta etapa usualmente se implementa ejecutando "make install".
+
|<code>%install</code>||<code>%_builddir</code>||<code>%_buildrootdir</code>||Esta lee los archivos dentro del directorio de construcción <code>%_builddir</code> y escribe a un directorio dentro del directorio raíz de construcción <code>%_buildrootdir</code>. Los archivos que son escritos son los que se supone serán instalados cuando el paquete binario sea instalado por el usuario final. Tenga cuidado con esta terminología algo extraña: El ''directorio raíz de construcción'' '''no''' es lo mismo que el ''directorio de construcción''. Esta etapa usualmente se implementa ejecutando «<code>make install</code>».
 
|-
 
|-
|bin||%_buildrootdir||%_rpmdir||Se leen los archivos bajo el directorio raíz de construcción %_buildrootdir (usualmente ~/rpmbuild/BUILDROOT/) para crear los paquetes binarios RPM en el directorio RPM %_rpmdir (usualmente ~/rpmbuild/RPMS/). Dentro del directorio RPM hay un directorio para cada arquitectura y un directorio "noarch" para los paquetes a los cuales no les aplica la arquitectura. Los archivos RPM son los paquetes para que los usuarios instalen.
+
|<code>bin</code>||<code>%_buildrootdir</code>||<code>%_rpmdir</code>||Este lee los archivos dentro del directorio raíz de construcción <code>%_buildrootdir</code> para crear los paquetes RPM binarios dentro del directorio RPM <code>%_rpmdir</code>. Adentro del directorio RPM hay un directorio para cada arquitectura, y un directorio "<code>noarch</code>" para los paquetes que se aplican a cualquier arquitectura. Estos archivos RPM son los paquetes para que instalen los usuarios.
|-
 
|src||%_sourcedir ||%_srcrpmdir||Esto crea un paquete fuente RPM (.src.rpm) dentro del directorio fuente RPM %_srcrpmdir (usualmente ~/rpmbuild/SRPMS). Estos archivos son necesarios para revisar y actualizar los paquetes.
 
 
|-
 
|-
 +
|<code>src</code>||<code>%_sourcedir</code>||<code>%_srcrpmdir</code>||Este crea un paquete fuente RPM (<code>.src.rpm</code>) dentro del directorio fuente RPM <code>%_srcrpmdir</code>. Estos archivos son necesarios para revisar y actualizar los paquetes.
 
|}
 
|}
  
Como puede notar, algunos directorios tienen propósitos específicos en rpmbuild. Estos son:
+
<!-- Nota: Las palabras «en» y «dentro» de la tabla anterior tienen diferentes significados. Dado el archivo /a/b/c, c es «dentro» pero no «en» a. -->
  
{|
+
Como podrá notar, algunos directorios tienen ciertos propósitos específicos en <code>rpmbuild</code>. Estos son:
!Nombre del macro!!Nombre!! Usualmente !!Propósito
+
{|border="1" cellspacing="0"
 +
! Nombre de la macro !! Nombre !! Usualmente !! Propósito
 
|-
 
|-
|%_specdir|| Directorio especificaciones ||~/rpmbuild/SPECS ||Archivos de especificaciones RPM (.spec).
+
|<code>%_specdir</code>||Directorio de especificación||<code>~/rpmbuild/SPECS</code>||Archivos de especificaciones RPM (<code>.spec</code>).
 
|-
 
|-
|%_sourcedir|| Directorio fuente|| ~/rpmbuild/SOURCES||Paquete fuente prístina (e.g., tarballs) y parches.
+
|<code>%_sourcedir</code>||Directorio fuente||<code>~/rpmbuild/SOURCES</code>||Paquete fuente prístina (por ejemplo, tarballs) y parches.
 
|-
 
|-
|%_builddir|| Directorio de construcción||~/rpmbuild/BUILD||Archivos fuente son desempacados y compilados en un subdirectorio bajo este directorio.
+
|<code>%_builddir</code>||Directorio de construcción||<code>~/rpmbuild/BUILD</code>||Los archivos fuentes son desempaquetados y compilados en un subdirectorio dentro de este.
 
|-
 
|-
|%_buildrootdir ||Directorio raíz de construcción|| ~/rpmbuild/BUILDROOT||Los archivos son instalados bajo este directorio durante la etapa %install .
+
|<code>%_buildrootdir</code>||Directorio raíz de construcción||<code>~/rpmbuild/BUILDROOT</code>||Los archivos son instalados bajo este directorio durante la etapa <code>%install</code>.
 
|-
 
|-
|%_rpmdir ||Directorio binario RPM ||~/rpmbuild/RPMS ||Los binarios RPM son creados y almacenados bajo este directorio.
+
|<code>%_rpmdir</code>||Directorio RPM binario||<code>~/rpmbuild/RPMS</code>||Los RPM binarios son creados y almacenados bajo este directorio.
|-
 
|%_srcrpmdir ||Directorio fuente RPM ||~/rpmbuild/SRPMS ||Los fuente RPM son creados y almacenados bajo este directorio.
 
 
|-
 
|-
 +
|<code>%_srcrpmdir</code>||Directorio RPM fuente||<code>~/rpmbuild/SRPMS</code>||Los RPM fuente son creados y almacenados bajo este directorio.
 
|}
 
|}
  
Si falla alguna etapa, deberá revisar la salida para ver por qué falló, y deberá cambiar el archivo .spec (u otra entrada) en la medida de lo necesario.
+
Si falla alguna etapa, tendrá que revisar la salida para ver ''por qué'' falló y deberá cambiar el archivo <code>.spec</code> (u otra entrada) cuando sea necesario.
  
= Preparándose a empaquetar un programa específico =
+
== Preparándose a empaquetar un programa específico ==
  
Si hay necesidad de instalar paquetes especiales para construir o ejecutar su programa a empaquetar, instale dichos programas y anote dónde se encontraron (usted necesitará la información).
+
Si se requieren programas especiales para construir o ejecutar el programa que está empaquetando, instale dichos programas y anote los que son.
  
Para empaquetar un programa usted debe empaquetar los fuentes originales (pristine) junto a los parches y las instrucciones de construcción. En general no es aceptable comenzar con un código precompilado. Instale el archivo con la fuente original (usualmente un archivo tar.gz) en el directorio "~/rpmbuild/SOURCES" de la cuenta de usuario para construcción de rpms.
+
Al empaquetar un programa para el repositorio de Fedora, debe empaquetar los fuentes prístina (originales), junto a los parches y las instrucciones de construcción;
 +
en general '''no''' es aceptable comenzar con un código precompilado. Instale el archivo con la fuente original (usualmente un archivo <code>.tar.gz</code>) en el directorio
 +
<code>~/rpmbuild/SOURCES</code> (de la cuenta de usuario para construcción de RPM).
  
Lea el manual de instrucciones para instalación de su programa, usted deberá automatizar esas tareas por medio de la edición de un archivo ".spec" así que deberá entender qué es lo que se supone debe hacer antes. Es probable que sea mejor que intente un "dry run", realizando el procedimiento de instalación sin hacerlo con RPM (esto es especialmete cierto si usted no está familiarizado con RPM).
+
Lea el manual de instrucciones para la instalación de su programa. A menudo es una buena idea hacer un «simulacro» construyendo manualmente el programa antes de intentar hacerlo a través de RPM. Con unas pocas excepciones, todos los binarios y librerías incluidas en los paquetes de Fedora deben construirse desde el código fuente que se incluye en el paquete fuente.
  
Intente reusar lo que pueda. Asegúrese que no está empacando algo que ya se encuentra empaquetado, usted puede encontrar la lista de paquetes en Fedora Package Collection en Fedora Package Database. Verifique también In Progress Review Requests (paquetes que actualmente están bajo revisión) y la lista Retired Packages. Garantizado ello, vea si alguien más ha comenzado a empaquetarlo para Fedora. Google por "PROGRAMNAME Fedora rpm" o similar, tal vez puede comenzar por dónde otra persona más quedó. Puede usar http://cvs.fedoraproject.org/viewcvs/rpms/ directamente para ver los archivos .spec (y parches) de cualquier paquete similar que ya se encuentre en Fedora. Usted puede descargar los fuentes RPMs utilzando un programa del paquete yum-utils:
+
=== Dividir el programa ===
  
    $  yumdownloader --source nombre-del-paquete
+
El código fuente de la aplicación es a menudo liberado con el código fuente de otras librerías externas «incluido» en ellos. [[Packaging:No_Bundled_Libraries|No junte librerías externas con la aplicación principal en un solo paquete]]. En cambio, divídelos en paquetes separados.
  
Alternativamente un fuente rpm (source rpm) puede ser descargado manualmente explorando algunos de los repositorio Fedora (ya sea via http o ftp).
+
=== Concesión de licencias ===
Seleccione releases/12/Everything/source/SRPMS (remplace "12" con la versión Fedora que desea) y descargue el fuente RPM de su elección (terminan en .src.rpm).
 
  
Una vez descargue el fuente RPM, ejecute el comando siguiente para instalar los fuentes a partir del src.rpm (como el usuario escogido, makerpm):
+
Sólo empaquete software que sea legal en su paquete. Ver [[Packaging:Guidelines#Legal]], [[Licensing:Main]] y [[Packaging:LicensingGuidelines]]. En general, sólo empaquete software que sea lanzado como software de código abierto (OSS) utilizando una licencia OSS aprobada (tales como las licencias GPL, LGPL, BSD-new, MIT/X, o Apache 2.0). Asegúrese de que el software realmente tiene licencia de esta manera (por ejemplo, verificar in situ los encabezados del código fuente, archivos README, etc.). Si hay librerías incluidas, asegúrese de que también son OSS.
  
  $ rpm -ivh sourcepackage-name*.src.rpm
+
=== Reutilizar la información del paquete existente ===
  
Este coloca el archivo .spec del paquete en el directorio ~/rpmbuild/SPECS y los otros fuentes y parches ~/rpmbuild/SOURCES).
+
Trate de reutilizar lo que se pueda. Obviamente, asegúrese de que no está empaquetando algo que ya ha sido empaquetado. Encontrará una lista de los paquetes existentes en la Colección de paquetes de Fedora en la [https://admin.fedoraproject.org/pkgdb/ Base de datos de paquetes de Fedora]. Compruebe también las [[PackageMaintainers/InProgressReviewRequests|Solicitudes de revisión en progreso]] y la lista de [[PackageMaintainers/RetiredPackages|Paquetes retirados]]. Puede utilizar los [http://pkgs.fedoraproject.org/cgit Repositorios de paquetes Git de Fedora] directamente para ver los archivos SPEC (y parches). Puede descargar los SRPMS utilizando un programa desde el paquete <code>yum-utils</code>:
 +
$ yum -y install yum-utils
 +
$ yumdownloader --source nombre-paquetefuente
  
También puede desempaquetar el .src.rpm en un directorio utilizando rpm2cpio:
+
Alternativamente, puede obtener el código fuente manualmente desde la página http/ftp de un [http://mirrors.fedoraproject.org/publiclist espejo de Fedora] dentro del directorio <code>releases/{{FedoraVersion}}/Everything/source/SRPMS</code>. Reemplace «<code>{{FedoraVersion}}</code>» con la versión de Fedora que desee y descargue el paquete <code>.src.rpm</code> que necesita.
  
  $ mkdir NOMBREDEPROGRAMA_src_rpm
+
Una vez que tiene el SRPM, instalarlo en <code>~/rpmbuild</code>:
  $ cd NOMBREDEPROGRAMA_src_rpm
+
$ rpm -ivh nombre-paquetefuente*.src.rpm
  $ rpm2cpio ../NOMBREDEPROGRAMA-*.src.rpm | cpio -i
 
  
Algunas veces es más fácil comenzar con un paquete existente y luego limpiarlo y prepararlo para Fedora. RPM Find RPM puede ayudarle a encontrar rpms para sistemas diferentes a Fedora. Usted puede instalar fuentes RPMs de otros sistemas de la misma forma que para los de Fedora. Si eso falla, usted puede localizar archivos de paquetes fuentes (no los paquetes binarios .deb) en Ubuntu o Debian (los paquetes fuentes son tarbals estandar posiblemene con un subdirectorio "debian"/ asociado a los archivos de parches). Si "FreeBSD".http://www.freebsd.org/ports/installing.html lo tiene, usted podría descargar de ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz y ver si la información de empaquetado existente le ayuda como punto de partida.
+
También puede desempaquetar el SRPM en un directorio usando <code>rpm2cpio</code>:
 +
$ mkdir NOMBREDEPROGRAMA_src_rpm
 +
$ cd NOMBREDEPROGRAMA_src_rpm
 +
$ rpm2cpio ../NOMBREDEPROGRAMA-*.src.rpm | cpio -i
  
Sin embargo, a veces eso no ayuda en nada. Las diferentes distribuciones tienen diferentes reglas y lo que hacen en algunos casos puede ser inapropiado para Fedora.
+
Algunas veces es más fácil comenzar con un paquete existente y luego limpiarlo y prepararlo para Fedora. [http://rpmfind.net/ RPM Find] puede ayudarle a encontrar RPM para sistemas diferentes a Fedora. Puede instalar SRPMS de otros sistemas de la misma forma que para los de Fedora. Si eso falla, puede localizar los archivos de paquetes fuentes (no los binarios <code>.deb</code>) en [http://packages.ubuntu.com/ Ubuntu] o [http://www.debian.org/distrib/packages Debian] (los archivos de paquetes fuentes son tarballs estándar con un subdirectorio «<code>debian/</code>»). Si la [http://www.freebsd.org/ports/installing.html colección de ports FreeBSD] lo tiene, podrí­a [ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz descargarlo del FreeBSD ports tarball] y ver si la información de empaquetado existente le ayuda como punto de partida. Sin embargo, esto a veces no es útil para todos. Las diferentes distribuciones tienen diferentes reglas y lo que hacen en algunos casos puede ser inapropiado para Fedora.
  
=Creando un archivo spec =
+
== Creando un archivo SPEC ==
  
Usted ahora necesita crear un archivo ".spec" en el directorio "~/rpmbuild/SPECS". Usted debería nombrarlo de acuerdo al nombre del programa, ej. "programa.spec", use el nombre de archivo o el nombre publicado por el autor del software.
+
Ahora necesita crear un archivo SPEC en el directorio <code>~/rpmbuild/SPECS</code>. Debería nombrarlo de acuerdo al nombre del programa (por ejemplo «<code>program.spec</code>»). Use donde se pueda el nombre de archivo o el nombre publicado por el autor del software, pero asegúrese de seguir los [[Packaging/NamingGuidelines|Lineamientos de nombres de paquetes]].
Creando un archivo spec en blanco¶
 
  
Cuando usted está creando un archivo spec por primera vez, usted puede crear su versión inicial utilizando emacs o vim, ellos crearán una plantilla para usted.
+
=== Plantillas de SPEC ===
  
 +
Al crear un archivo SPEC por primera vez, vim o emacs crearán automáticamente una plantilla para usted:
 
   $ cd ~/rpmbuild/SPECS
 
   $ cd ~/rpmbuild/SPECS
   $ vi program.spec
+
   $ vim program.spec
 
 
Abajo un ejemplo de como luce la plantilla creada:
 
 
 
Name:       
 
Version:   
 
Release:    1%{?dist}
 
Summary:   
 
Group:       
 
License:   
 
URL:       
 
Source0:   
 
BuildRoot:    %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 
 
BuildRequires:   
 
Requires:   
 
  
 +
He aquí un ejemplo de lo que se verá como plantilla ('''Nota:''' la plantilla que se ofrece no necesariamente cumple con los Lineamientos de empaquetado de Fedora):
 +
Name:
 +
Version:
 +
Release: 1%{?dist}
 +
Summary:
 +
Group:
 +
License:
 +
URL:
 +
Source0:
 +
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 +
 +
BuildRequires:
 +
Requires:
 +
 
  %description
 
  %description
 
+
 
  %prep
 
  %prep
 
  %setup -q
 
  %setup -q
 
+
 
  %build
 
  %build
 
  %configure
 
  %configure
 
  make %{?_smp_mflags}
 
  make %{?_smp_mflags}
 
+
 
  %install
 
  %install
 
  rm -rf %{buildroot}
 
  rm -rf %{buildroot}
 
  make install DESTDIR=%{buildroot}
 
  make install DESTDIR=%{buildroot}
 
+
 
  %clean
 
  %clean
 
  rm -rf %{buildroot}
 
  rm -rf %{buildroot}
 
+
 
  %files
 
  %files
 
  %defattr(-,root,root,-)
 
  %defattr(-,root,root,-)
 
  %doc
 
  %doc
 
+
 
  %changelog
 
  %changelog
  
Usted puede tener $RPM_BUILD_ROOT en vez de %{buildroot}; sólo por consistencia.
+
Puede usar <code>$RPM_BUILD_ROOT</code> en lugar de <code>%{buildroot}</code>. Ambos son aceptables, pero sólo para ser más consistente.
  
Usted puede tambien usar el comando rpmdev-newspec para que le cree un nuevo archivo spec. rpmdev-newspec NOMBRE-DE-UN-NUEVO-PAQUETE le puede crear un archivo spec inicial para un nuevo paquete que se puede ajustar a varios tipos de paquetes. Este programa intentará adivinar qué tipo de plantilla basándose en el nombre del paquete, o usted puede especificarle una plantilla particular, vea las plantillas disponibles en /etc/rpmdevtools/spectemplate-*.spec . Vea rpmdev-newspec --help para más información. Por ejemplo, para crear un nuevo archivo spec para un módulo python:
+
También puede usar el comando <code>rpmdev-newspec</code> para crear un archivo SPEC para usted. <code>rpmdev-newspec NOMBRE-DE-NUEVO-PAQUETE</code> puede crear un archivo SPEC inicial para un nuevo paquete, adaptado a varios tipos de paquetes. Adivinará también qué tipo de plantilla utilizar basándose en el nombre del paquete, o puede especificarle una plantilla en particular. Vea las plantillas disponibles en <code>/etc/rpmdevtools/spectemplate-*.spec</code>, y consulte <code>rpmdev-newspec --help</code> para más información. Por ejemplo, para crear un nuevo archivo SPEC para un módulo python:
  
 
  cd ~/rpmbuild/SPECS
 
  cd ~/rpmbuild/SPECS
  rpmdev-newspec python-antigravedad
+
  rpmdev-newspec python-antigravity
  vi python-antigravedad.spec
+
  vi python-antigravity.spec
  
= Un ejemplo: eject =
+
=== Ejemplo de SPEC ===
  
Sigue un ejemplo simple, un paquete Fedora 9 para el programa "eject":
+
He aquí un ejemplo simple que muestra un archivo SPEC de Fedora 16 para el programa <code>eject</code>:
  
Summary: A program that ejects removable media using software control
+
<pre>
Name: eject
+
Summary:           A program that ejects removable media using software control
Version: 2.1.5
+
Name:               eject
Release: 11%{dist}
+
Version:           2.1.5
License: GPL
+
Release:           21%{?dist}
Group: System Environment/Base
+
License:           GPLv2+
Source: http://metalab.unc.edu/pub/Linux/utils/disk-management/%{name}-%{version}.tar.gz
+
Group:             System Environment/Base
Source1: eject.pam
+
Source:             %{name}-%{version}.tar.gz
Patch1: eject-2.1.1-verbose.patch
+
Patch1:             eject-2.1.1-verbose.patch
Patch2: eject-timeout.patch
+
Patch2:             eject-timeout.patch
Patch3: eject-2.1.5-opendevice.patch
+
Patch3:             eject-2.1.5-opendevice.patch
Patch4: eject-2.1.5-spaces.patch
+
Patch4:             eject-2.1.5-spaces.patch
Patch5: eject-2.1.5-lock.patch
+
Patch5:             eject-2.1.5-lock.patch
Patch6: eject-2.1.5-umount.patch
+
Patch6:             eject-2.1.5-umount.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
+
URL:               http://www.pobox.com/~tranter
URL: http://www.pobox.com/~tranter
+
ExcludeArch:       s390 s390x
ExcludeArch: s390 s390x
+
BuildRequires:     gettext
BuildRequires: gettext
+
BuildRequires:     libtool
BuildRequires: automake
 
BuildRequires: autoconf
 
BuildRequires: libtool
 
  
%description
+
%description
The eject program allows the user to eject removable media (typically
+
The eject program allows the user to eject removable media (typically
CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software
+
CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software
control. Eject can also control some multi-disk CD changers and even
+
control. Eject can also control some multi-disk CD changers and even
some devices' auto-eject features.
+
some devices' auto-eject features.
  
Install eject if you'd like to eject removable media using software
+
Install eject if you'd like to eject removable media using software
control.
+
control.
  
%prep
+
%prep
%setup -q -n %{name}
+
%setup -q -n %{name}
%patch1 -p1 -b .versbose
+
%patch1 -p1
%patch2 -p1 -b .timeout
+
%patch2 -p1
%patch3 -p0 -b .opendevice
+
%patch3 -p1
%patch4 -p0 -b .spaces
+
%patch4 -p1
%patch5 -p0 -b .lock
+
%patch5 -p1
%patch6 -p1 -b .umount
+
%patch6 -p1
  
%build
+
%build
%configure
+
%configure
make
+
make %{?_smp_mflags}
  
%install
+
%install
rm -rf %{buildroot}
+
make DESTDIR=%{buildroot} install
  
make DESTDIR=%{buildroot} install
+
install -m 755 -d %{buildroot}/%{_sbindir}
 +
ln -s ../bin/eject %{buildroot}/%{_sbindir}
  
# pam stuff
+
%find_lang %{name}
install -m 755 -d %{buildroot}/%{_sysconfdir}/pam.d
 
install -m 644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/pam.d/%{name}
 
install -m 755 -d %{buildroot}/%{_sysconfdir}/security/console.apps/
 
echo "FALLBACK=true" > %{buildroot}/%{_sysconfdir}/security/console.apps/%{name}
 
  
install -m 755 -d %{buildroot}/%{_sbindir}
+
%files -f %{name}.lang
pushd %{buildroot}/%{_bindir}
+
%doc README TODO COPYING ChangeLog
mv eject ../sbin
+
%{_bindir}/*
ln -s consolehelper eject
+
%{_sbindir}/*
popd
+
%{_mandir}/man1/*
  
%find_lang %{name}
+
%changelog
 +
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 2.1.5-21
 +
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
  
%clean
+
* Fri Jul 02 2010 Kamil Dudka <kdudka@redhat.com> 2.1.5-20
rm -rf %{buildroot}
+
- handle multi-partition devices with spaces in mount points properly (#608502)
 +
</pre>
  
%files -f %{name}.lang
+
{{Anchor|Spec_file_pieces_explained}}
%defattr(-,root,root)
+
== Resumen del archivo SPEC ==
%doc README TODO COPYING ChangeLog
 
%attr(644,root,root) %{_sysconfdir}/security/console.apps/*
 
%attr(644,root,root) %{_sysconfdir}/pam.d/*
 
%{_bindir}/*
 
%{_sbindir}/*
 
%{_mandir}/man1/*
 
  
%changelog
+
Otras guías útiles:
* Wed Apr 02 2008 Zdenek Prikryl &lt;zprikryl at, redhat.com&gt; 2.1.5-11
+
* [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html Guía RPM] describe cómo escribir un archivo SPEC.
- Added check if device is hotpluggable
+
* Las series de IBM «Empaquetado de software con RPM» [http://www.ibm.com/developerworks/ssa/linux/library/l-rpm1/ Parte 1], [http://www.ibm.com/developerworks/ssa/linux/library/l-rpm2/ Parte 2], y [http://www.ibm.com/developerworks/ssa/linux/library/l-rpm3/ Parte 3].
- Resolves #438610
+
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM] tiene la información más completa, pero es anticuado.
  
Usted tambien puedes usar el "BuildRoot:" en vez de acceso desde la plantilla, aunque ambas son aceptables, la opción desde la plantilla es la preferida.
+
Usted deberá seguir los lineamientos Fedora: [[Packaging/NamingGuidelines|Lineamientos de nombres de paquetes]], [[Packaging/Guidelines|Lineamientos de empaquetado]], y [[Packaging/ReviewGuidelines|Lineamientos de revisión de paquetes]].
  
= Explicando las partes de un archivo spec =
+
Insertar los comentarios con el primer carácter «<code>#</code>», pero evite las macros (comienzan con <code>%</code>) que sean potencialmente multilíneas (las que se expanden primero). Si está comentando una línea, doble los signos de porcentaje (<code>%%</code>). Evite también los comentarios inline en la misma línea como un comando de script.
  
El RPM Guide, section on creating RPMs, describe los detalles de cómo rellenar un archivo spec.
+
Las principales etiquetas se enumeran a continuación. Tenga en cuenta que las macros <code>%{name}</code>, <code>%{version}</code> y <code>%{release}</code> pueden utilizarse para hacer referencia a las etiquetas Name, Version y Release respectivamente. Cuando cambia la etiqueta, las macros se actualizan automáticamente para utilizar el nuevo valor.
 +
* '''Name''': El nombre (base) del paquete, que debe coincidir con el nombre del archivo SPEC. Debe seguir los [[Packaging/NamingGuidelines|Lineamientos de nombres de paquetes]] y generalmente estar en minúsculas.
 +
* '''Version''': El número de versión de desarrollo. Vea la [[Packaging/NamingGuidelines#Version_Tag|Sección etiqueta de versión]] en los lineamientos de empaquetado. Si la versión contiene etiquetas que no son numéricas (contiene etiquetas que no son números), puede que necesite incluir caracteres no numéricos adicionales en la etiqueta Release. Si el desarrollo utiliza fechas completas para distinguir las versiones, considere usar números de versión con la forma <code>yy.mm[dd]</code> (por ejemplo <code>2008-05-01</code> se convierte en <code>8.05</code>).
 +
* '''Release''': El valor inicial normalmente debería ser <code>1%{?dist}</code>. Incremente el número cada vez que libere un nuevo paquete para la misma versión de software. Cuando una nueva versión de desarrollo es liberada, cambiar la etiqueta Version para igualar y restablecer el número de Release a <code>1</code>. Vea la [[Packaging/NamingGuidelines#Release_Tag|Sección etiqueta de versión]] en los lineamientos de empaquetado. La [[Packaging/DistTag|etiqueta opcional Dist]] podría ser útil.
 +
* '''Summary''': Un breve, sumario del paquete en una línea. Use inglés americano. Y '''no''' termine con un punto.
 +
* '''Group''': Este tiene que ser un grupo pre-existente, como «Applications/Engineering»; ejecute «<code>less /usr/share/doc/rpm-*/GROUPS</code>» para ver la lista completa. Use el grupo «Documentation» para los sub-paquetes (por ejemplo <code>kernel-doc</code>) que contienen documentación. '''''Nota: Esta etiqueta está en desuso desde Fedora 17. Consulte [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Spec_File_Reference-Preamble.html Preámbulo de referencia del archivo Spec]'''''
 +
* '''License''': La licencia, debe ser una licencia de software de código abierto. ''No'' usar la antigua etiqueta Copyright. Utilizar una abreviatura estándar (por ejemplo «<code>GPLv2+</code>») y ser específico (por ejemplo use «<code>GPLv2+</code>» para la GPL versión 2 o superior en lugar de simplemente «<code>GPL</code>» o «<code>GPLv2</code>» cuando sea cierto). Consulte [[Licensing]] y los [[Packaging/LicensingGuidelines|Lineamientos de licencias]]. Usted puede listar múltiples licencias combinándolas con «<code>and</code>» y «<code>or</code>» (por ejemplo «<code>GPLv2 and BSD</code>»).
 +
* '''URL''': La dirección URL completa para obtener más información sobre el programa (por ejemplo, la página web del proyecto). '''''Nota: Esta no es de donde proviene el código fuente original que sirve para la etiqueta Source0 de abajo'''''.
 +
* '''Source0''': La dirección URL completa para el archivo comprimido que contiene el código fuente (original) prístina, liberado como desarrollo. «<code>Source</code>» es sinónimo de «<code>Source0</code>». Si usted da una dirección URL completa (y debería), su nombre base será utilizado cuando se busque en el directorio <code>SOURCES</code>. Si es posible, insertar <code>%{name}</code> y <code>%{version}</code>, así los cambios en cualquiera de ellas irá al lugar adecuado. [[Packaging:Guidelines#Timestamps|Preservar los datos]] al descargar archivos fuentes. Si existe más de un archivo fuente, nómbrelos como <code>Source1</code>, <code>Source2</code> y así sucesivamente. Si va a añadir nuevos archivos completos, además de las fuentes originales, lístelos como fuentes ''después'' de las fuentes prístinas. Una copia de cada una de estas fuentes serán incluídas en cualquier SRPM que cree, a menos que específicamente le indique lo contrario. Vea [[Packaging/SourceURL|Source URL]] para obtener más información sobre los casos especiales (por ejemplo, control de revisión).
 +
* '''Patch0''': El nombre del primer parche para aplicar al código fuente. Si necesita parchear los archivos después de que hayan sido descomprimidos, debe editar los archivos y guardar sus diferencias como un archivo «patch» en su directorio <code>~/rpmbuild/SOURCES</code>. Los parches deben hacer sólo un cambio lógico cada uno, así que es muy posible tener varios archivos de parches.
 +
* '''BuildArch''': Si está empaquetando archivos que son independientes de la arquitectura (por ejemplo, scripts de shell, archivos de datos), agregar «<code>BuildArch: noarch</code>». La arquitectura para el RPM binario será entonces «<code>noarch</code>».
 +
* '''BuildRoot''': Esta es dónde los archivos serán «instalados» durante el proceso %install (después del proceso %build). Esta es ahora redundante en Fedora y sólo es necesaria para EPEL5. De forma predeterminada, la raíz de construcción se coloca en «<code>%{_topdir}/BUILDROOT/</code>».
 +
* '''BuildRequires''': Una lista separada por comas de paquetes requeridos para la construcción (compilar) del programa. Este campo se puede (y lo es comúnmente) repetir en varias líneas. Estas dependencias ''no'' son determinadas automáticamente, usted debe incluir ''todo'' lo necesario para construir el programa. [[Packaging/Guidelines#BuildRequires|Algunos paquetes comunes se pueden omitir]], tal como <code>gcc</code>. Puede especificar una versión mínima si es necesario (por ejemplo «<code>ocaml >= 3.08</code>»). Si necesita el archivo <code>/EGGS</code>, determinar el paquete que lo posee mediante la ejecución de «<code>rpm -qf /EGGS</code>». Si necesita el programa <code>EGGS</code>, determinar el paquete que lo posee mediante la ejecución de «<code>rpm -qf `which EGGS`</code>». Mantener las dependencias al mínimo (por ejemplo use <code>sed</code> en vez de <code>perl</code> si realmente no necesita las capacidades de perl), pero tenga en cuenta que algunas aplicaciones desactivan funciones permanentemente si la dependencia asociada no está presente; en estos casos deberá incluir los paquetes adicionales. El paquete {{package|auto-buildrequires}} puede ser útil.
 +
* '''Requires''': Una lista separada por comas de los paquetes que se requieren cuando se instala el programa. Tenga en cuenta que la etiqueta BuildRequires lista lo que se necesita para construir el RPM binario, mientras que la etiqueta Requires lista lo que se requiere para la instalación/ejecución del programa; un paquete puede estar en una lista o en ambas. En muchos casos, <code>rpmbuild</code> detecta automáticamente las dependencias por lo que la etiqueta Requires no siempre es necesaria. Sin embargo, puede que desee resaltar algunos paquetes específicos cuando sea necesario, o es posible que no sean detectados automáticamente.
 +
* '''%description''': Una más larga, descripción multilínea del programa. Use inglés americano. Todas las líneas deben ser de 80 caracteres o menos. Las líneas en blanco indican un nuevo párrafo. Algunos programas de instalación de la interfaz gráfica de usuario reformatearán los párrafos; las líneas que comienzan con un espacio en blanco se tratan como texto preformateado y se mostrarán tal cual, normalmente con una fuente de ancho fijo. Consulte [http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s03.html Guía RPM].
 +
* '''%prep''': Comandos de script para «preparar» el programa (por ejemplo, para descomprimirlo) y que pueda estar listo para la construcción. Típicamente es sólo «<code>%setup -q</code>»; una variación común es «<code>%setup -q -n NOMBRE</code>» si el archivo fuente se desempaqueta en <code>NOMBRE</code>. Consulte la sección %prep de abajo para más detalles.
 +
* '''%build''': Comandos de script para «construir» el programa (por ejemplo, para compilarlo) y prepararlo para la instalación. El programa debe venir con instrucciones de cómo hacerlo. Vea la sección %build de abajo para más detalles.
 +
* '''%check''': Comandos de script para «probar» el programa. Estos se ejecutan entre los procedimientos %build e %install, así que debe colocarlo allí si tiene esta sección. A menudo simplemente contiene «<code>make test</code>» o «<code>make check</code>». Esto es aparte de %build para que las personas puedan omitir la comprobación automática si lo desean.
 +
* '''%install''': Comandos de script para «instalar» el programa. Los comandos deben copiar los archivos desde el directorio de <code>CONSTRUCCIÓN</code> <code>%{_builddir}</code> al directorio raíz de construcción, <code>%{buildroot}</code>. Vea la sección %install de abajo para más detalles.
 +
* '''%clean''': Instrucciones para limpiar la raíz de construcción. Tenga en cuenta que esta sección es ahora redundante en Fedora y sólo es necesaria para EPEL. Normalmente esto sólo contiene:
 +
rm -rf %{buildroot}
 +
* '''%files''': La lista de archivos que serán instalados. Consulte la sección %files de abajo para más detalles.
 +
* '''%changelog''': Cambios en el paquete. Utilice de ejemplo el formato anterior.
 +
* '''ExcludeArch''': Si el paquete no compila, construye o funciona correctamente en una arquitectura en particular, liste esas arquitecturas bajo esta etiqueta.
 +
* Puede agregar secciones para que el código se ejecute cuando los paquetes sean instalados o removidos en el sistema real (en lugar de sólo ejecutar el script %install, que sólo hace una pseudo-instalación a la raíz de construcción). Estos se denominan «scriptlets», y se utilizan generalmente para actualizar el sistema en ejecución con información del paquete. Consulte la sección «Scriptlets» de abajo para más detalles.
  
La serie developerWorks en "Packaging software with RPM" Part 1 , Part 2 , y Part 3 son también útiles.
+
RPM también soporta la creación de varios paquetes (llamados [[How_to_create_an_RPM_package/es#Subpaquetes|subpaquetes]]) desde un único archivo SPEC, como los paquetes <code>name-libs</code> y <code>name-devel</code>.
  
Maximum RPM tiene la información más completa, pero no es reciente.
+
'''No''' use estas etiquetas:
 +
* Packager
 +
* Vendor
 +
* Copyright
  
Usted deberá seguir los lineamientos Fedora, tales como los especificados en Package Naming Guidelines,
+
'''No''' cree un paquete «relocalizable»; que no agrega valor en Fedora y hace las cosas más complicadas.
Packaging Guidelines y Package review guidelines.
 
  
Usted puede insertar comentarios precediendo la línea con "#", pero no inserte macros-potencialmente-multilineas, palabras que comiencen con "%", en un comentario, los macros son expandidos primero. Si está comentando una línea, doble los simbolos de porcentaje ("%%"). Tampoco use comentarios inline ("#") en la misma línea justo después de un comando script.
+
== Secciones del archivo SPEC explicadas ==
  
Aquí se comentan los campos/areas principales que deberá rellenar:
+
=== Sección %prep ===
* Name: El nombre (base) del paquete. Debe estar conforme a las normas Package Naming Guidelines. En muchos casos, será todo en letras minúsculas. En cualquier lugar del archivo spec usted puede referirse al nombre utilizando el macro %{name} - de esa forma, si el nombre cambia, el nuevo nombre será utilizado por esas otras locaciones donde se utiliza. Este nombre debería coincidir con el nombre de archivo del archivo spec.
 
* Version: El número de versión aguas arriba (upstream). Vea Packaging/Naming guidelines - package version para más información. Si la versión no es numérica (contiene marcas que no son números o dígitos), puede que necesite incluir caracteres no numéricos adicionales en el campo release. Si aguas arriba se usan fechas completas para distinguir las versiones, considere usar números de versión de la forma yy.mm[dd] (de tal que la liberación 2008-05-01 se convierte en 8.05). En cualquier lugar del archivo spec, refiérase esta valor como %{version}.
 
* Release: El valor inicial de release debería normalmente ser "1%{?dist}". Entonces, incremente el número cada vez que libere un nuevo paquete para la misma versión de software. Si se está empaquetando y liberando una nueva versión del software, el número de versión debería ser cambiado para reflejar la nueva versión de software y el número de liberación (release) debería ser restablecido a 1. Vea Name Guidelines - package release para más información. Packaging/DistTag describe la marca "dist", la cual no es requerida pero puede ser útil. Use %{release} para reusar este valor.
 
* Summary: Una breve, de una línea, descripción del paquete. Use American English, y no termine con punto.
 
* Group: Este debe ser un nombre de grupo existente, como "Applications/Engineering", ejecute "less /usr/share/doc/rpm-*/GROUPS" para ver la lista completa. Si usted crea un subpaquete, "...-doc" con documentation, use el grupo "Documentation".
 
* License: La licencia, para software, debe ser una licencia de fuente abierta. Use las abreviaciones estandar, e.g., "GPLv2+". Intente ser específico, e.g., use "GPLv2+" (GPL version 2 or greater) en vez de solo "GPL" o "GPLv2" cuando esto sea cierto. Vea Licensing y lo lineamientos en Licensing Guidelines para más información. Usted puede listar múltiples licencias combinándolas con "and" y "or", e.g., "GPLv2 and BSD". Llame a esta marca "License", no use la marca antigua "Copyright".
 
* URL: El URL para conseguir más información acerca del programa, e.g., el sitio web del proyecto. Nota: Este NO es de donde provino el código fuente original, vea "Source" (a continuación!).
 
* Source0: El URL para conseguir el archivo comprimido que contiene los fuentes (originales) prístinas, como se ha liberado aguas arriba. "Fuente" es sinónimo de "Source0". Si usted define un URL completo (y debería), su nombre base será utilizado cuando se busque en el directorio SOURCES. Si posible, agregue %{name} y %{version}, así los cambios a cualquiera de ellas irá al lugar adecuado. Alerta: Source0: y URL: son diferentes , normalmente ambos son URLs, pero la entrada "URL:" apunta al sitio web del proyecto, mientras que "Source0:" apunta al archivo que contiene el código fuente (y es típicamente un archivo .tar.gz). Como está anotado en los lineamientos, "cuando descargue fuentes, parches, etc, considere usar un cliente que preserve las marcas de tiempo aguas arriba. Por ejemplo wget -N o curl -R. Para hacer el cambio algo global para wget, agregue lo siguiente a su ~/.wgetrc: timestamping = on, and for curl, agregue a su ~/.curlrc: -R." Si existe más de un fuente, nómbrelos como Source1, Source2, y así. Si está agregando nuevos archivos completos además de las fuentes prístinas, usted puede listar cada uno como fuentes también, pero lístelos después de las fuentes prístinas. Una copia de cada una de estas fuentes serán incluídas en cualquier paquete fuente que cree (a menos que específicamente le indique lo contrario). Vea "Packaging/SourceURL"https://fedoraproject.org/wiki/Packaging/SourceURL para más información de casos especiales (uso de control de revisión, cuando aguas arriba usa código prohibido, etc).
 
* Patch0: El nombre del primer parche que aplicará al código fuente. Si necesita parchar los archivos después de descomprimir, usted debería editar los archivos, salvar sus diferencias como archivo "patch" en su directorio ~/rpmbuild/SOURCES. Los parches deberían hacer un único cambio lógico, así que muy probable que tenga múltiples archivos de parches (patch).
 
* BuildRoot: Esto es dónde los archivos serán "instalados" durante el proceso "%install" (que ocurre después de proceso de compilación build). Normalmente usted debería dejar esta línea sin modificación, bajo la configuración Fedora usual, este será un macro que creará un directorio nuevo especial bajo /var/tmp. La próxima versión por salir de RPM ignorará este valor y en su lugar la raíz de construcción será "{_topdir}/BUILDROOT/".
 
* BuildRequires: Una lista separada por comas de paquetes requeridos para construir (compilar) el programa. Estos no son determinados automáticamente, así que usted debe incluir todo lo necesario para construir el programa. Hay algunos pocos paquetes que son tan comunes en las compilaciones que usted no necesitará mencionarlos, tal como "gcc"; vea Packaging Guidelines para ver la lista completa de paquetes que puede omitir. También puede especificar versiones mínimas requeridas, si es necesario, asi: "ocaml >= 3.08". Usted puede tener más de una línea de BuildRequires (en cuyo caso son todas ellas requeridas para compilación). Si necesita el archivo /EGGS, puede obtener su paquete corriendo "rpm -qf /EGGS"; si EGGS es un programa, usted determina su paquete rápidamente ejecutando rpm -qf `which EGGS`". Intente especificar la menor cantidad posible de paquetes necesarios para construir apropiadamente el paquete ya que cada uno desacelerará el proceso una construcción basada en "mock" (e.g., intente usar sed en vez de perl si realmente no necesita las habilidades de perl). Tenga cuidado, algunas aplicaciones deshabilitan permanentemente funciones si su paquete no es detectado durante la compilación, en dichos casos puede que necesite incluir dichos paquetes adicionales.
 
* Requires: Una lista de paquetes separados por coma que son requeridos cuando el programa es instalado. Note que la lista de paquetes para Requires (lo que es requerido cuando se instala/ejecuta) y BuildRequires (lo que se requiere para compilar el RPM binario) son independientes, un paquete puede estar presente en una lista pero no en la otra o pudiera estar en ambas listas. Las dependencias de los paquetes binarios son en muchos casos automáticamente detectadas por rpmbuild asi que es común el caso de que no se requiere especificar Requires para nada. Pero si desea resaltar algunos paquetes como requeridos, o requerir algún paquete que rpm no pueda detectar, entonces agréguelo aqui.
 
* %description - Una descripción más larga del programa, multilínea. Use Inglés Americano. Todas las líneas deben ser de ochenta (80) caracteres o menos. Se asume que las líneas en blanco son párrafos separados. Algunos programas de instalación GUI reformatearán los párrafos, la líneas que comienzan con un espacios en blanco, tales como espacio o tabulador, serán tratados como texto preformateado y lo mostrarán tal cual es, normalmente con una fuente de ancho fijo (de acuerdo a RPM Guide).
 
* %prep - Comandos guión para "preparar" el programa, esto es, descomprimirlo tal que esté listo para construcción (compilación). Típicamente es sólo "%setup -q" o alguna variación, una variación común es "%setup -q -n NAME" si el archivo fuente desempaca en NAME. Vea la sección "%prep" abajo para más detalles.
 
* %build - Comandos guión para "construir" el programa, esto es, compilarlo y alistarlo para instalación. El programa debería venir con instrucciones de cómo hacerlo. Vea la sección "%build" abajo para más detalles.
 
* %check - Comandos guión para auto-probar el programa. Estos se ejecutan justo después de %build y antes de %install, así que debería colocarlo si usted tienen dicha sección. A menudo simplemente contiene "make test" o "make check". Esto es aparte de %build asi que las personas pueden saltarse la auto-prueba si lo desean. Esto no tampoco está documentando en muchas partes.
 
* %install - Comando guión para "instalar" el programa. Los comandos deben copiar los archivos desde el "directorio de construcción" %{_builddir} (que estaría debajo de ~/rpmbuild/BUILD) en el directorio raíz de construcción, %{buildroot} (que normalmente estaría bajo /var/tmp). Vea la sección "%install" abajo para más detalles.
 
* %clean - instrucciones para limpiar la raíz de construcción. Típicamente: rm -rf %{buildroot}
 
* %files - la lista de archivos que serán instalados. Vea la sección "%files" para más detalles.
 
* %changelog - Cambios en el paquete. Use el formato que se especifica abajo.
 
* ExcludeArch: Si el paquete no compila exitosamete, construye o funciona en una o más arquitecturas dadas, entonces dichas arquitecturas deberían ser listadas en el spec con la marca ExcludeArch.
 
* Usted puede agregar secciones de tal forma que su código será ejecutado cuando los paquetes sean instalados o removidos en el sistema real (en oposición a sólo ejecutar el guión %install, que sólo seudoinstala a la raíz de construcción). Estos se denomina "scriptlets", y son usualmente utilizados para actualizar el sistema en ejecución con la información contenida en el paquete. Vea la sección "Scriptlets" para más detalles.
 
  
No use las marcas "Packager" o "Vendor". No use la marca "Copyright" - use en su sustitución "License".
+
La sección %prep describe cómo desempaquetar los paquetes comprimidos para que puedan ser construidos. Típicamente, esto incluye los comandos «<code>%setup</code>» y «<code>%patch</code>» con referencia a las líneas Source0 (y Source1, etc.). Vea la [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html sección %setup y %patch en Maximum RPM] para más detalles.
  
No cree un paquete "relocalizable" - ellos no agregan valor en Fedora aun y complican las cosas.
+
Las macros %{patches} y %{sources} están disponibles desde RPM 4.4.2 y son útiles si usted tiene una gran lista de parches o fuentes:
 +
for p in %{patches}; do
 +
    ...
 +
done
  
RPM soporta subpaquetes, esto es, un único archivo spec puede generar varios paquetes binarios. Por ejemplo, si la documentación es muy larga, usted puede generar un subpaquete aparte "-doc". Vea más detalles abajo.
+
Sin embargo, tenga en cuenta que el uso de estas hará a su SPEC incompatible con los RPMS utilizados en RHEL y otras distribuciones basadas en RPM.
  
= Sección %prep =
+
==== Sección %prep: comando %setup ====
  
La sección "%prep" describe cómo desempacar los paquetes comprimidos y asi poderlos luego, construir. Típicamente es un conjunto de comando "%setup" y/o %patch, que referencian Source0, Source1, etc.
+
El comando «<code>%setup</code>» desempaqueta un paquete fuente. Los modificadores incluyen:
 +
* '''<code>-q</code>''' : Suprime la salida innecesaria. Este es comúnmente utilizado.
 +
* '''<code>-n</code> ''nombre''''' : Si el archivo tarball Fuente se desempaqueta en un directorio cuyo nombre no es el nombre del RPM, este modificador puede utilizarse para especificar el nombre del directorio correcto. Por ejemplo, si el archivo tarball se desempaqueta en el directorio FOO, use «<code>%setup -q -n FOO</code>».
 +
* '''<code>-c</code> ''nombre''''' : Si el archivo tarball Fuente se desempaqueta en varios directorios en lugar de un solo directorio, este modificador puede utilizarse para crear un directorio llamado ''nombre'' y luego descomprimir en él.
  
Vea Maximum RPM section on %setup and %patch para más detalles.
+
Hay [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html más opciones %spec si está desempaquetando múltiples archivos], lo cual es especialmente útil si está creando subpaquetes (ver más abajo). Las más importantes son:
  
Alerta: En los archivos spec, no use comentarios en-línea (un "#" en la misma línea después de un comando), y no coloque macros (palabaras que comienzan con "%") en un comentario a menos que lo cite con "%" como "%%". Los macros pueden provocar fallos si se comentan porque ellos siempre son expandidos (incluso en líneas comentadas) y pueden expandir a múltiples líneas. Esto es cierto para %prep, %build, y subsiguientes.
+
{|
 +
|-
 +
| <code>-a número</code> || Sólo desempaquetar la directiva Fuente del número dado después de cambiar de directorio (por ejemplo «<code>–a 0</code>» para Source0).
 +
|-
 +
| <code>-b número</code> || Sólo desempaquetar la directiva Fuente del número dado antes de cambiar de directorio (por ejemplo «<code>–b 0</code>» para Source0).
 +
|-
 +
| <code>-D</code> || No eliminar el directorio antes de desempaquetar.
 +
|-
 +
| <code>-T</code> || Inhabilitar el desempaquetado automático del archivador.
 +
|}
  
La nueva serie RPM 4.4.2.x agregó dos nuevos macros, %{patches} y %{sources}, con los que puede hacer cosas como:
+
==== Sección %prep: comando %patch ====
  
for p in %{patches}; do
+
El comando «<code>%patch0</code>» aplica el Parche0 (y %patch1 aplica Parche1, etc.). Los parches son el método habitual de realizar los cambios necesarios en el código fuente para el empaquetamiento. La usual opción «<code>-pNUMERO</code>» se aplica, la que pasa ese argumento al <code>patch</code> en el programa.
...
 
done
 
 
 
Estos nuevos macros pueden ser muy poderosos si tiene una larga lista de parches o fuentes. Sin embargo, mantenga presente que usarlos hará su spec incompatible con el rpm utilizado en Fedora 9 y anteriores, RHEL, y muchas otras distribuciones basadas en RPM.
 
Sección %prep: comando %setup
 
El comando "%setup" desempaquete un paquete fuente y toma varias opciones (switches). Normalmente usted usará -q (quiet/silencioso) para evitar que los ajustes sean visibles a cada cambio de archivo que se desempaqueta. Abajo le mostramos otras opciones diferentes aparte de -q:
 
* -n nombre: Si el nombre del rpm es algo diferente a lo que la Fuente desempaca, use esta opción para establecer el nombre a donde desempaquetar. E.G., si el tarball desempaca en el directorio MINOMBRE, use %setup -q -n MINOMBRE.
 
* -c nombre: Si el tarball no desempaca en un único directorio, esto crea un directorio nombre y luego desempaca en él. Es útil si usted tiene uno de esos molestos tarballs que no tienen un único directorio embutido en ellos.
 
 
 
Estas son más opciones %spec si está desempaquetando mútliples archivos , que es primordialmente útil si está creando subpaquetes (vea más abajo). Las más importantes son:
 
*-a número Sólo desempaqueta la directiva fuente de número dado, tal como –a 0 para source0:, después de cambiarse al directorio.
 
*-b número Sólo desempaqueta la directiva fuente de número dado, tal como –b 0 para source0:, antes de cambiarse al directorio.
 
*-D No eliminar el directorio antes de desempaquetar.
 
*-T Deshabilita el desempaquetado automático de archivos.
 
 
 
= Sección %prep: comandos %patch =
 
 
 
El comando "%patch0" aplica el parche 0 (similar para 1, 2, etc.). La opción "-pNUMERO" aplica, simplemente pasa el argumento a patch. Los nombres de los archivos parche usualmente lucen como "telnet-0.17-env.patch",esto es, -{version}-propósito_del_parche.patch , algunas personas omiten - %{version}. Los archivos parche son típicamente el resultado de un comando "diff -u", si usted hace eso desde el subdirectorio de ~/rpmbuild/BUILD, usted no tiene que especificar -p level después. Usted puede usar todas las formas normales de crear achivos parche. Si usted está creando un archivo parche para un archivo único NOMBREDEARCHIVO, una forma común de hacerlo es copiar a NOMBREDEARCHIVO.orig, modificarlo, y luego guardar el resultado como "diff -u NOMBREDEARCHIVO.orig NOMBREDEARCHIVO":
 
  
cp X/Y.Z X/Y.Z.orig
+
Los nombres de los archivos parche usualmente lucen como «<code>telnet-0.17-env.patch</code>», que es el formato «<code>%{name} - %{version} - RAZÓN.patch</code>» (aunque a veces se omite la versión). Los archivos parche son típicamente el resultado de «<code>diff -u</code>»; si hace esto desde el subdirectorio <code>~/rpmbuild/BUILD</code> entonces no tendrá que especificar un nivel <code>-p</code> posterior.
vim X/Y.Z
 
diff -u X/Y.Z.orig X/Y.Z > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch
 
  
Si editará muchos archivos, un método fácil es copiar el subdirectorio completo bajo BUILD, y luego hacer diffs por subidrectorio, una vez que se encuentre en BUILD/loquesea, usted puede hacer:
+
Este es un procedimiento típico para crear un parche para un solo archivo:
 +
cp foo/bar foo/bar.orig
 +
vim foo/bar
 +
diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/NOMBREDEPAQUETE.RAZÓN.patch
  
  cp -pr . ../NOMBREDEPAQUETE.orig
+
Si va a editar muchos archivos, un método fácil es copiar el subdirectorio completo debajo de <code>BUILD</code> y luego hacer diffs por subdirectorio. Después de cambiar al directorio «<code>~rpmbuild/BUILD/NOMBRE</code>», haga lo siguiente:
 +
  cp -pr ./ ../NOMBREDEPAQUETE.orig/
 
  ... muchas ediciones ...
 
  ... muchas ediciones ...
  diff -u ../NOMBREDEPAQUETE.orig . > ~/rpmbuild/SOURCES/NOMBREDEPK.RASON.patch   << ojo aqui, no entendí bien, ver el original si duda.
+
  diff -u ../NOMBREDEPAQUETE.orig . > ~/rpmbuild/SOURCES/''NOMBRE''.''RAZÓN''.patch
 
 
Si usted edita muchos archivos en un parche, también puede copiar los archivos originales utilizando una finalización consistente como ".orig" antes de editarlos. Luego, puede usar "gendiff" (en el paquete rpm) para crear un parche con las diferencias. Vea "man gendiff" para más información.
 
 
 
Intente asegurar que su parche el "contexto" hace coincidencia exacta. Por omisión, patch intentará aplicar los parches incluso cuando la coindicencia es imprecisa con valor "fuzz" de 2, pero "el nuevo RPM para Fedora 10!:http://lwn.net/Articles/289235/ cambiará el valor por omisión de fuzz a 0. Usted puede darle la vuelta agregando "%define _default_patch_fuzz 2", pero es mejor no tener el problema.
 
  
Usted debería enviar su parche hacia aguas arriba, y documentar en su archivo spec el email/bug de aguas arriba que lo incluye. Vea PatchUpstreamStatus .
+
Si edita muchos archivos en un parche, también puede copiar los archivos originales mediante alguna terminación consistente como «<code>.orig</code>» antes de editarlos. Luego, puede usar «<code>gendiff</code>» (en el paquete <code>rpm-build</code>) para crear un parche con las diferencias.
  
= Sección %prep : Archivos sin modificación =
+
Trate de asegurarse que el parche coincida exactamente con el contexto. El valor por omisión de «fuzz» es «<code>0</code>», que requiere coincidencia para ser exacto. Puede solucionar esto añadiendo «<code>%global _default_patch_fuzz 2</code>» para volver al valor encontrado en las versiones anteriores de RPM en Fedora, pero en general se recomienda evitar hacer esto.
  
Algunas veces usted empaquetará un archivo simple que no requiere ser descomprimido, e.g., un "Source1:" que simplemente es un archivo PDF. Esto no aplica desde fuentes externas, e.g., tal vez usted ha creado unos archivos adicionales que no se encontraban en los fuentes originales de tal que el paquete instale limpiamente en Fedora. Usted puede "prep" esos archivos en el directorio de construcción haciendo lo siguiente (remplace "1" con el número adecuado):
+
Como se explica en [[Packaging/PatchUpstreamStatus]], todos los parches deben tener un comentario sobre ellos en el archivo SPEC sobre su estado de desarrollo. Este debe documentar el desarrollo que incluye los errores/correo electrónico (incluyendo la fecha). Si es exclusivo de Fedora, debe mencionar por qué es único. El proyecto Fedora intenta no desviarse del desarrollo; consulte [[PackageMaintainers/WhyUpstream]] para ver la importancia de esto.
  
  cp -p %SOURCE1 .
+
==== Sección %prep: Archivos sin modificar ====
  
= Sección %build =
+
A veces, uno o más de los archivos Fuente no necesitarán ser descomprimidos. Usted puede «prep» esos archivos en un directorio de construcción como este (donde <code>SOURCE1</code> se refiere al archivo Fuente correspondiente):
 +
cp -p %SOURCE1 .
  
La sección "%build" es algunas veces complicada, aquí usted configura y compila/construye los archivos a ser instalados.
+
=== Sección %build ===
  
Muchos programas siguen la forma GNU configure (o alguna variación). Por omisión, instalarán con prefijo "/usr/local" (/usr/local/bin, /usr/local/lib, etc.), que es un valor por omisión razonable para archivos desempaquetados. Sin embargo, ya que usted está empaquetándolo, usted deseará cambiar el prefijo (prefix) a "/usr" ya que desde ahora este es un paquete mantenido por el sistema mismo. Si hay librerías, ellas deben ser instaladas en el directorio adecuado que es /usr/lib o /usr/lib64 dependiendo de la arquitectura (el valor actual está en %{_libdir}).
+
La sección «%build» es a veces complicada; aquí usted configura y compila/construye los archivos a ser instalados.
  
Ya que el sistema "configure" de GNU es tan común, rpm predefine un macro denominado "%configure", que invoca el GNU configure con las opciones adecuadas (e.g., cambia --prefix a /usr). Esto significa que alguna variación de esto usualmente funcionará como comando de construcción:
+
Muchos programas siguen el enfoque <code>configure</code> de GNU (o alguna variación). De forma predeterminada, se instalarán con un prefijo de «<code>/usr/local</code>», que es razonable para los archivos desempaquetados. Sin embargo, como usted está empaquetándolo, cambiará el prefijo a «<code>/usr</code>». Las librerías deben instalarse bien sea en <code>/usr/lib</code> o <code>/usr/lib64</code> dependiendo de la arquitectura.
  
 +
Ya que <code>configure</code> de GNU es tan común, la macro «<code>%configure</code>» se puede utilizar para invocar automáticamente las opciones correctas (por ejemplo, cambiar el prefijo a <code>/usr</code>). Alguna variación de esto a menudo funciona:
 
   %configure
 
   %configure
 
   make %{?_smp_mflags}
 
   make %{?_smp_mflags}
  
Algunas veces usted querrá sobrescribr las variables de un archivo makefile, ello lo puede lograr fácilmente pasándolas como parámetros a make, asi:
+
Para sustituir variables en el makefile, pasarlas como parámetros a <code>make</code>:
 +
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}
  
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}
+
Más información, consulte [http://sourceware.org/autobook/ «GNU autoconf, automake, and libtool»] y [http://www.suse.de/~sh/automake/automake.pdf «Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf» por Stefan Hundhammer].
  
Si necesita hacerlo complicado con el configure-GNU generado, dele un vistazo a GNU autoconf, automake, and libtool . Una buena presentación al respecto al igual que de "make" es Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf by Stefan Hundhammer .
+
Algunos programas usan <code>cmake</code>. Ver [[Packaging/cmake]].
  
Algunos programas usan Cmake. Vea algunas sugerencias en Empaquetando con cmake .
+
=== Sección %check ===
  
Si incluye algunas autopruebas (y ello es buena idea), colóquelas en una sección "%check" aparte inmediatamente después del área "%build", en vez de incluir dichas pruebas en %build. De esta forma será fácil para el sistema saltarse las pruebas innecesarias.
+
Si las pruebas automáticas están disponibles, por lo general es una buena idea incluirlas. Deben colocarse en la sección %check (que sigue inmediatamente a la sección %build) en lugar de dentro de la sección %build, de modo que puedan ser fácilmente omitidas cuando sea necesario.
= Sección %check =
 
  
La sección"%check" hace pruebas, usualmente es "make test". Esto no está documentado en mucha otras fuentes de información RPM.
+
A menudo, esta sección contiene:
= Sección %install =
+
make test
  
La sección "%install" es un conjunto de guiones (scripts) para "instalar" el programa. Los comandos en esta sección deberían copiar los archivos del directorio dentro del "directorio de construcción" %{_builddir} (normalmente ~/rpmbuild/BUILD/_algo_) hacia el directorio raíz de construcción, %{buildroot} (normalmente /var/tmp/_algo_ o ~/rpmbuild/BUILDROOT), creando los directorios dentro de %{buildroot} en la medida de lo necesario.
+
=== Sección %install ===
  
Cuidado: la terminología puede ser algo confusa en algunos casos:
+
Esta sección incluye comandos de script para «instalar» el programa, copiar los archivos relevantes desde <code>%{_builddir}</code> a <code>%{buildroot}</code> (que por lo general significa desde <code>~/rpmbuild/BUILD</code> a <code>~/rpmbuild/BUILDROOT</code>) y la creación de directorios dentro de <code>%{buildroot}</code> según sea necesario.
* El directorio de construcción (build directory), bajo el cual ocurren las compilaciones durante %build, y la raíz de construcción (build root), donde los archivos son copiados durantel el proceso %install, son diferentes. El objeto del proceso %install es copiar archivos, tales como los archivos bajo el directorio de construcción, al luegar correcto en la raíz de construcción. Talvez "buildroot" debiése llamarse "installroot", pero es demasiado tarde ahora, la terminología está muy anidada.
 
* El directorio de construcción es normalmente ~/rpmbuild/BUILD, mientras que la raíz de construcción, donde se instalan los archivos durante install, es normalmente ~/rpmbuild/BUILDROOT. La etapa %prep normalmente creará un subdirectorio bajo el directorio de construcción como parte de %setup y lo poblará con archivo, basándose en información fuente en %_sourcedir, que es típicamente en ~/rpmbuild/SOURCES. Durante %build, el directorio actual de hecho comenzará siendo %{buildsubdir}, ese nuevo subdirectorios creado bajo el directorio de construcción. Típicamente %{buildsubdir} es algo como ~/rpmbuild/BUILD/{name}-%{version}.
 
* El guión "%install" no es utilizado cuando el paquete binario rpm es instalado por el usuario final. El término "%install" es confuso, de hecho el guión no debe instalar el programa en las ubcaciones REALES finales (e.g., en /usr/bin), sino bajo el buildroot %{buildroot}.
 
  
Normalmente el guión install primero borrará el directorio , luego hará alguna variación de "make install" (idealmente utilizando DESTDIR={buildroot}, si el programa lo soporta. Abajo un ejemplo de una sección %install:
+
Parte de la terminología que puede inducir a error:
 +
* El «directorio de construcción», también conocido como <code>%{_builddir}</code> no es el mismo que el «raíz de construcción», también conocido como <code>%{buildroot}</code>. La compilación se produce en el primer directorio, mientras que los archivos a ser empaquetados son copiados desde el primero al último.
 +
* Durante la sección de %build, el directorio actual comenzará en <code>%{buildsubdir}</code>, que es el subdirectorio dentro de <code>%{_builddir}</code> creado durante la etapa de %prep. Esto suele ser algo como <code>~/rpmbuild/BUILD/%{name}-%{version}</code>.
 +
* La sección %install '''no''' no se ejecuta cuando el paquete RPM binario es instalado por el usuario final, pero sólo se ejecuta cuando se crea un paquete.
  
 +
Normalmente, una variación de «<code>make install</code>» se lleva a cabo aquí:
 
  %install
 
  %install
 
  rm -rf %{buildroot}
 
  rm -rf %{buildroot}
  make DESTDIR=%{buildroot} INSTALL="install -p" CP="cp -p" install
+
  make DESTDIR=%{buildroot} install
  
Idealmente cada programa tendrá un comando "make install" que soporte ls convención DESTDIR. Si el programa incluye un "make install" que soporte DESTDIR, cuando se posible, úselo. La convención DESTDIR soporta redireccionar las instalaciones de archivos para descender de un director5io específico, que es exactamente lo que se desea durante %install.
+
La eliminación de <code>%{buildroot}</code> ya no es necesaria, excepto para EPEL 5.
  
Instalar un programa que no soporte DESTDIR puede ser mucho más difícil y ninguna otra opción mejor como el soporte nativo a DESTDIR. Considere estas alternativas:
+
Idealmente debe usar [http://www.gnu.org/prep/standards/html_node/DESTDIR.html <code>DESTDIR=%{buildroot}</code>] si el programa lo admite, ya que redirige las instalaciones del archivo al directorio especificado y es exactamente lo que queremos que ocurra durante la sección %install.
* Parchar el makefile de tal que si soporte DESTDIR. Cree los directorios dentro de DESTDIR cuando sea necesario (siéntase libre de usar "mkdir -p", la opción "-p" es ahora estandar y ampliamente soportada). Asegúrese de enviar el parche aguas arriba.
 
* Use "%makeinstall". Muchos documentos antiguos acerca de RPM sugieren usar "%makeinstall", que puede funcionar si "make install" no soporta DESTDIR. Sin embargo, así como se indica en los lineamientos Fedora, el macro makeinstall "NO debe ser usado cuando make install DESTDIR={buildroot} funcione. makeinstall es (meramente) una forma improvisada que puede funcionar con Makefiles que no hacen uso de la variable DESTDIR...". Desafortunadamente, esto a veces tiene fallas imprevistas, por lo que %makeinstall no deber ser usado si DESTDIR funciona. La razón está basada en el cómo funciona %makeinstall. El macron "%makeinstall" expande a algo como "<tt>make prefix={buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install</tt>". Muchos programas recompilarán silenciosamente o cambiarán partes del programa cuando valores como prefix cambian, resultando en una instalación incorrecta. Vea los lineamientos Fedora si desea urgar en los detalles de por qué este método puede fallar. Usted probablemente necesitará crear los directorios apropiados dentro de buildroot antes de llamar a %makeinstall (e.g., <tt>mkdir -p %{buildroot}{_bindir}/</tt>).
 
* Considere usar el paquete auto-destdir. Esto requiere "BuildRequires: auto-destdir", y cambiar "make install" a "make-redir DESTDIR=%{buildroot} install". Esto sólo funciona bien si la instalación usa sólo ciertos comandos para instalar archivos, como cp e install, vea "man make-redir" para los detalles.
 
* Haga la instalación "a mano", esto es, en vez de invocar un sistema de construcción, copie los archivos a las ubicaciones correctas. Básicamente esto sería una secuencia de creación de directorios que aun no existiesen y on fuese creados por los "BuildRequires" de paquetes (típicamente usando install -d o mkdir -p), seguida del copiado de archivos del directorio actual (dentro del directorio de construcción) hacia el directorio raíz de construcción (tipicamente usando "cp -p" y/o "install -p"). Ejecutar "make -n install" puede hacer más fácil el determinar cuál es la secuencia que debiése seguirse. Asegúrese de crear los directorios dentro de %buildroot cuando sea necesario. Un problema serio con esta técnica es que es fácil fallar al instalar archivos nuevos o renombrados durante una actualización, asi que si hay una mejor técnica, úsela. Si usted hace una instalación "a mano", tenga especial cuidado con las actualizaciones. Por ejemplo:
 
  
 +
Si el programa no admite <code>DESTDIR</code> (y sólo si), es posible la solución en una de las varias formas (inferiores):
 +
* Parchar el makefile así es compatible con <code>DESTDIR</code>. Crear directorios dentro de <code>DESTDIR</code> cuando sea necesario y enviar el parche a desarrollo.
 +
* Usar la macro «<code>%makeinstall</code>». Este método podría funcionar, pero puede conducir a fallas sutiles. Se expande a algo así como «<code>make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install</code>», lo cual puede resultar que en algunos programas no funcione correctamente. Crear directorios dentro de <code>%{buildroot}</code> cuando sea necesario.
 +
* Considerar la posibilidad de usar el paquete <code>auto-destdir</code>. Para ello es necesario «<code>BuildRequires: auto-destdir</code>», y cambiar «<code>make install</code>» por «<code>make-redir DESTDIR=%{buildroot} install</code>». Esto sólo funciona bien si la instalación utiliza sólo ciertos comandos comunes para instalar los archivos, como <code>cp</code> e <code>install</code>.
 +
* Realizar la instalación a mano. Esto implicaría crear los directorios necesarios debajo de <code>%{buildroot}</code> y copiar los archivos desde <code>%{_builddir}</code> a <code>%{buildroot}</code>. Tenga especial cuidado con las actualizaciones, que a menudo contienen nombres de archivos nuevos o modificados. Un ejemplo de este procedimiento:
 
  %install
 
  %install
 
  rm -rf %{buildroot}
 
  rm -rf %{buildroot}
Line 384: Line 395:
 
  cp -p mycommand %{buildroot}%{_bindir}/
 
  cp -p mycommand %{buildroot}%{_bindir}/
  
De acuerdo a los lineamientos, "cuando agregue comandos de copiado en el archivo spec, considere usar el comando que preserve las marcas de tiempo de los archivos, eg. cp -p o install -p". Si, el makefile le permite sobrescribir el comando install (típicamente llamado INSTALL), usted podría poner algo como INSTALL="install -p" CP="cp -p" como parámetros make, así:
+
Como se indica en [[Packaging:Guidelines#Timestamps]], tratar de preservar las marcas de tiempo de los archivos si el makefile permite sobrescribir comandos:
 
 
 
  make INSTALL="install -p" CP="cp -p" DESTDIR=%{buildroot} install
 
  make INSTALL="install -p" CP="cp -p" DESTDIR=%{buildroot} install
  
= Sección %files =
+
=== Sección %files ===
 
+
Esta sección declara que los archivos y directorios son propiedad del paquete, por lo tanto los archivos y directorios se colocan en el RPM binario.
La sección %files identifica los archivos y directorios agregados por el paquete, y así entonces, cuáles archivos y directorios son propiedad del paquete. La propiedad es importante, cuando usted tipea "rpm -qif bla" usted podrá visualizar a quién pertenece bla .
 
 
 
= Fundamentos %files =
 
  
La sección %files normalmente comienza con una línea %defattr que define los permisos de los archivos por omisión. El formato de la línea es %defattr(<permisos de achivo>, <usuario>, <grupo>, <permisos de directorio>), esto significa que puede especificar los permisos que aplican a los archivos y directorios en la sección %files. El cuarto parámetro es a veces omitido. Usualmente se usa %defattr(-,root,root,-), donde "-" significa "use los permisos por omisión".
+
==== Conceptos básicos de %files ====
  
Esta línea es seguida por nombres o patrones de directorios o archivos que serán instalados y propiedad de este paquete. Usted debería usar macros para los nombres de directorio, e.g., use %{_bindir}/miarchivo en vez de /usr/bin/miarchivo, y %{_sbindir}/killaccount en vez de /usr/sbin/killaccount. Si un nombre o patrón comienza con"/" cuando se expande, entonces se presume que ha sido copiado en %{buildroot} seguido de dicho patrón, cuando se instale en sistema final, será copiado en ese nombre sin el prefijo buildroot. Si usted no precede con "/", entonces se presume estar en el directorio actual (e.g., dentro del directorio de construcción) - esto se usa para archivos de "documentación". Asi que si su paquete sólo instala /usr/bin/micomando, entonces su sección %files podría ser simplemente:
+
La <code>%defattr</code> establece los permisos de archivo por defecto, y se encuentra a menudo en el inicio de la sección <code>%files</code>. Tenga en cuenta que esto ya no es necesario a menos que los permisos deban modificarse. El formato de esta es:
 +
%defattr(<permisos de achivo>, <usuario>, <grupo>, <permisos de directorio>)
 +
El cuarto parámetro se omite a menudo. Usualmente se utiliza <code>%defattr(-,root,root,-)</code>, donde «<code>-</code>» significa use los permisos predeterminados.
  
 +
A continuación, debe listar todos los archivos y directorios a ser propiedad del paquete. Utilizar macros para los nombres de directorio donde sea posible, que pueden verse en [[Packaging:RPMMacros]] (por ejemplo, utilice <code>%{_bindir}/mycommand</code> en lugar de <code>/usr/bin/mycommand</code>). Si el patrón comienza con una «<code>/</code>» (o cuando se expande desde la macro) entonces se toma desde el directorio <code>%{buildroot}</code>. De lo contrario, se presume que el archivo está en el directorio actual (por ejemplo dentro de <code>%{_builddir}</code>, como los archivos de documentación que desee incluir). Si su paquete sólo instala un único archivo <code>/usr/sbin/mycommand</code>, la sección <code>%files</code> simplemente puede ser:
 
  %files
 
  %files
%defattr(-,root,root,-)
 
 
  %{_sbindir}/mycommand
 
  %{_sbindir}/mycommand
  
Cualquier archivo o directorio identificado en la sección %files es propiedad del paquete que lo define. Usted debería asegurarse que declare la propiedad para cada nuevo archivo o directorio que el paquete cree. Puede utilizar wildcards (*) que abarquen a un grupo de archivos, esto hace que el paquete sea menos sensible a los cambios. Por ejemplo, usted puede declarar que todos los archivos que fuesen copiados en en %{buildroot}/usr/bin fuesen propiedad de este paquete declarando:
+
Para hacer que su paquete sea menos sensible a los cambios, declare que todos los archivos dentro de un directorio sean propiedad del paquete con una coincidencia de patrón:
 
 
 
  %{_bindir}/*
 
  %{_bindir}/*
  
Note que "%{_bindir}/*" no reclama que este paquete es dueño del directorio /usr/bin - reclama que todos los archivos que fueron instalados dentro del ''build root'' 's /usr/bin son propiedad del paquete. Si usted lista un directorio in la sección files, entonces usted está reclamando que este paquete es dueño de ese directorio y todos sus archivos en él, recursivamente (todos hacia abajo ) si están presentes en la raíz de construcción. No liste los directorios "/usr/bin" o "{_bindir}" directamente en sus lista files porque ello reclamaría la propiedad de /usr/bin y todo dentro de él. El reclamar la propiedad de "{_bindir}/*" está bien, ya que sólo reclama la propiedad de los subdirectorio y archivos que usted coloque bajo /{_bindir}. Si crea un subdirectorio tal como /{name}, (/usr/share/NAME), usted debería incluir el directorio en la lista %files:
+
Para incluir un solo directorio:
 
 
 
  %{_datadir}/%{name}/
 
  %{_datadir}/%{name}/
  
Usualmente es más fácil utilizar wildcards para los nombres de archivo, y también es mejor que copiar con cambios aguas arriba. La documentación antigua RPM típicamente muestra largos listados bajo %files con nombres individuales, tal como /usr/bin/programa1 seguido de /usr/bin/programa2. Debido a la forma como Fedora usar buildroots ahora, esto ya no es necesario.
+
Tenga en cuenta que <code>%{_bindir}/*</code> no reclama que este paquete sea propietario del directorio <code>/usr/bin</code>, pero sólo de los archivos contenidos en él. Si usted lista un directorio, entonces usted está reclamando que este paquete sea dueño de ese directorio y de todos sus archivos y subdirectorios contenidos en él. Por lo tanto, '''no''' liste el <code>%{_bindir}</code> y tenga cuidado con los directorios que puedan ser compartidos con otros paquetes.
  
Es un eror si ningún archivo hace coincidencia con el wildcard en la línea, así que sólo liste los directorios que de hecho importan. Tampoco puede identificar el mismo archivo o directorio más de una vez. Finalmente, es un error tener algo en el buildroot y no listado bajo %files, el punto de copiar algo en el buildrott es porque usted pretende tenerlo instalado en el sistema final. Si usted no pretende eso, remueva dichos archivos durante el proceso %install.
+
Se producirá un error si:
 +
* una coincidencia de patrón no coincide con algún archivo o directorio
 +
* un archivo o directorio está listado o coincide más de una vez
 +
* un archivo o directorio en la <code>%{buildroot}</code>  no ha sido listado
  
También es posible excluir archivos de la coincidencia anterior utilizando el glob %exclude. Esto puede ser útil para incluir "casi todo" los archivos que hacen coincidencia con glob diferente. Sin embargo, note que, como cualquier otro glob, incluso el glob %exclude fallará si no hace coincidencia con algo. Esto puede parecer contraintuitivo ya que el objetivo es esencialmente asegurarse de que cierto archivo NO exté ahí, así que esta regla es particularmente importante que la recuerde.
+
También es posible excluir archivos de una coincidencia anterior utilizando el glob <code>%exclude</code>. Esto puede ser útil para incorporar a casi todos los archivos incluidos por una coincidencia de patrón diferente, pero tenga en cuenta que también fallará si no coincide con algo.
= Prefjos %files =
 
  
Usted puede necesitar agregar uno o más prefijos a la entrada %files (si es más de una, use espacio en blanco para separarlos).
+
==== Prefijos de %files ====
 +
Puede que tenga que agregar uno o más prefijos a las líneas en la sección <code>%files</code>; separados con un espacio. Ver [http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html Max RPM section on %files directives].
  
Típicamente hay una entrada "%doc" con una lista de archivos de documentación que no fueron copiados en el buildroot, usualmente al menos hay un archivo README y un archivo LICENSE. Usted debe incluir un archivo para la licencia., si es que hay uno. Usted puede prefijar algunos de éstos con attr(mode, user, group) para definir los permisos del archivo, el usuario y el grupo. Uste no necesita reclamar la propiedad del directorio /usr/share/doc/{name} , ello es automático. Cualquier entrada %doc no debe afectar la aplicación en tiempo de ejecución (si está en %doc, el programa debe ejecutarse apropiadamente si no están presentes).
+
Por lo general, «<code>%doc</code>» se utiliza para listar los archivos de documentación dentro de <code>%{_builddir}</code> que no se copiaron a <code>%{buildroot}</code>. Usualmente se incluyen los archivos <code>README</code> e <code>INSTALL</code>. Serán colocados en el directorio <code>/usr/share/doc/%{name}-%{version}</code>, cuya propiedad no necesita ser declarada.
  
Si usted guarda archivos de configuración (bajo /etc - no los coloque bajo /usr), usted debería prefijarlos con %config(noreplace) a menos que esta versión de programa use un formato de configuración no compatible hacia atrás (en cuyo caso, prefíjelos con %config).
+
'''Nota:''' Si se especifica una entrada <code>%doc</code>, entonces usted no puede copiar los archivos en el directorio de documentación durante la sección <code>%install</code>. Si, por ejemplo, desea un subdirectorio «ejemplos» dentro del directorio de documentación, no utilice <code>%doc</code>, pero en cambio cree los directorios y copie los archivos manualmente en <code>%{buildroot}%{_defaultdocdir}/%{name}-%{version}</code> durante la sección %install. Serán marcados correctamente como documentación. Asegúrese de incluir <code>%{_defaultdocdir}/%{name}-%{version}/</code> como una entrada en la sección %files.
  
Prefijar las entradas %files con "%attr(mode, user, group)" le permite establecer los permisos para archivos particulares, e.g., "%attr(0644, root, root)". Un "-" significa "usa los valores por omisión".
+
Los archivos de configuración deben ser colocados en <code>/etc</code> y normalmente son especificados como esto (lo que hace es asegurarse de que al actualizar no se sobrescriban los cambios hechos por el usuario):
 +
%config(noreplace) %{_sysconfdir}/foo.conf
 +
Si la actualización utiliza un formato de configuración no compatible con versiones anteriores, entonces especificarlo de la siguiente manera:
 +
%config %{_sysconfdir}/foo.conf
  
Si un archivo está en un lenguaje natural particular, use %lang para anotarlo. E.G.:
+
«<code>%attr(mode, user, group)</code>» puede ser utilizado para un mayor control sobre los permisos, donde un «<code>-</code>» significa utilizar el valor predeterminado:
 +
%attr(0644, root, root) FOO.BAR
  
 +
Si un archivo está en un idioma natural en particular, use <code>%lang</code> para asentarlo:
 
  %lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*
 
  %lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*
  
Algunas documentaciones dicen que %license y %readme son prefijos válidos, no lo son, en Fedora. Use en sustitución %doc.
+
Los programas que utilizan archivos Locale deben seguir el [[Packaging:Guidelines#Handling_Locale_Files|método recomendado para el manejo de archivos de i18n]]:
= %files y el Filesystem Hierarchy Standard (FHS) =
+
* encontrar los nombres de archivo en la etapa <code>%install</code>: <code> %find_lang ${name}</code>
 +
* añadir las dependencias de construcción necesarias: <code>BuildRequires: gettext</code>
 +
* utilizar los nombres de archivos encontrados: <code>%files -f ${name}.lang</code>
  
Usted debería seguir el estandar Filesystem Hierarchy Standar, i.e., los ejecutable de aplicaciones ordinarias van en /usr/bin, los archivos de configuración global en /etc, las librerías ordinarias en /usr/lib, y así, con una excepción, los ejecutables que no deberían normalmente ser ejecutados por usuarios o administradores, deberían ir al subdirectorio /usr/libexec, usualmente usted se referirá al directorio necesario como "%{_libexecdir}/%{name}".
+
Estos prefijos '''no''' son válidos en Fedora: <code>%license</code> y <code>%readme</code>.
  
Usted no debería instalar archivos bajo /usr/local, allí es donde van los archivos no empaquetados. Típicamente existirá un atributo "prefijo" que le permitirá definir el prefijo para que sea "/usr" en vez de "/usr/local".
+
==== %files y Estándar de jerarquía del sistema de archivos (FHS) ====
  
Desafortunadamente las rutinas "normales" de instalación de muchos programas no siguen el FHS. En particular muchos programas colocarán la librerías dependientes de la arquitectura bajo /usr/lib, en vez de bajo /usr/share como lo manda el FHS. El FHS /usr/lib section indica que /usr/lib para datos "dependientes" de la arquitecturar (e.g., archivos ELF como los archivos .so), mientras que /usr/share es para datos "independientes" de la arquitectura. De esa forma, los sistemas con diferentes CPUs pueden compartir /usr/share. Hay muchas excepciones a esta regla en Fedora (e.g., Python y Perl), pero Fedora aplica esta regla lo más estrictamente que otras distribuciones. Note, por ejemplo, que rpmlint se quejará si usted coloca cualquier otra cosa que archivos ELF en /usr/lib.
+
Usted debería seguir el [http://www.pathname.com/fhs/ Estándar de jerarquía del sistema de archivos (FHS)]. Los ejecutables van en <code>/usr/bin</code>, los archivos de configuración global en <code>/etc</code>, las librerías en <code>/usr/lib</code> (o <code>/usr/lib64</code>) y así sucesivamente. Hay una excepción: los ejecutables que no deberían ser ejecutados directamente por los usuarios o administradores deben ir en el subdirectorio <code>/usr/libexec</code>, lo que se conoce como <code>%{_libexecdir}/%{name}</code>.
==== Ejemplo %files ====
 
  
Aqui sigue un ejemplo simple de una sección %files:
+
'''No''' instalar los archivos en <code>/opt</code> o <code>/usr/local</code>.
  
 +
Desafortunadamente, muchos programas no siguen el FHS por defecto. En particular, las librerías independientes de la arquitectura se encontrarán en <code>/usr/lib</code> en lugar de <code>/usr/share</code>. El primero es para las librerías dependientes de la arquitectura, mientras que el segundo es para las librerías independientes de la arquitectura, lo que significa que los sistemas con arquitecturas de CPU diferentes pueden compartir en <code>/usr/share</code>. Hay muchas excepciones en Fedora (como Python y Perl), pero Fedora aplica esta regla más estrictamente que algunas distribuciones. <code>rpmlint</code> generalmente se quejará si usted pone algo más que archivos ELF en <code>/usr/lib</code>.
 +
 +
==== Ejemplo de %files ====
 +
 +
He aquí un ejemplo simple de una sección %files:
 
  %files
 
  %files
%defattr(-,root,root,-)
 
 
  %doc README LICENSE
 
  %doc README LICENSE
 
  %{_bindir}/*
 
  %{_bindir}/*
 
  %{_sbindir}/*
 
  %{_sbindir}/*
 
  %{_datadir}/%{name}/
 
  %{_datadir}/%{name}/
 +
%config(noreplace) %{_sysconfdir}/*.conf
 +
 +
==== Búsqueda de duplicados ====
 +
 +
Puede listar los duplicados de dos paquetes binarios haciendo:
 +
cd ~/rpmbuild/RPMS/ARCH # Sustituir «ARCH» por su arquitectura
 +
rpm -qlp PACKAGE1.*.rpm | sort > ,1
 +
rpm -qlp PACKAGE2.*.rpm | sort > ,2
 +
comm -12 ,1 ,2
  
==== Scriptlets ====
+
=== Scriptlets ===
  
Usted puede agregar secciones de tal que el código correrá cuando los paquetes sean instalados o removidos en el sistema real (en oposición a solo correr el guión %install, que sólo hace una pseudoinstalación en la raíz de construcción). Estos son denominados "scriptlets", y son usualmente utilizados para actualizar el sistema en ejecución con información existente en el paquete.
+
Cuando un usuario final instala el RPM, es posible que desee ejecutar algunos comandos. Esto se puede lograr a través de scriptlets. Consulte [[Packaging/ScriptletSnippets]].
  
Los scriptlets en %pre y %post se ejecutan antes y después de la instalación (respectivamente). Los scriptlets %preun and %postun son ejecutado antes y después de que el paquete es desinstalado, respectivamente. Los scriptlets %pretrans y %posttrans son ejecutados al comienzo y al final de la transacción. Vea Packaging/ScriptletSnippets para más ejemplos y detalles. Por ejemplo, cada RPM binario que almacena librerías compartidas (no sólo symlinks) en cualquier de las rutas por omisión del enlazador dinámico, debe llamar a ldconfig en %post y %postun (post-install y post-uninstall). Si el paquete tiene múltiples subpaquetes con librerías, cada subpaquete debería también tener una sección %post/%postun que llame a /sbin/ldconfig. Por ejemplo:
+
Los scriptlets se pueden ejecutar:
 +
* antes ('''<code>%pre</code>''') o después ('''<code>%post</code>''') de instalar un paquete
 +
* antes ('''<code>%preun</code>''') o después ('''<code>%postun</code>''') de desinstalar un paquete
 +
* al inicio ('''<code>%pretrans</code>''') o al final ('''<code>%posttrans</code>''') de una transacción
  
 +
Por ejemplo, cada paquete RPM binario que almacena archivos de las librerías compartidas en cualquiera de las rutas de acceso predeterminadas del enlazador dinámico, debe llamar a <code>ldconfig</code> en <code>%post</code> y <code>%postun</code>. Si el paquete tiene varios subpaquetes con librerías, cada subpaquete también debe realizar las mismas acciones.
 
  %post -p /sbin/ldconfig
 
  %post -p /sbin/ldconfig
 
  %postun -p /sbin/ldconfig
 
  %postun -p /sbin/ldconfig
  
Alerta: La opción "-p" especifica cual _command proccesor _ usar para los comandos en las siguientes líneas. Si no hay líneas siguientes, entonces si usa /sbin/ldconfig como el "command processor" es una mejora menor en eficiencia comparada con colocar "/sbin/ldconfig" en la siguiente línea y dejando al shell que lo invoque. Esto es así por que al usar la opción "-p" el shell no es invocado simplemente para invocar un único programa. Pero si tiene múltiples comando shell, no use "-p" o /sbin/ldconfig después! En sustitución, déjese en blanco, e incluya los comando shell justo abajo.
+
Si tan sólo ejecuta un solo comando, entonces la opción «<code>-p</code>» ejecuta el comando adyacente sin invocar el shell. Sin embargo, para varios comandos, omita esta opción e incluya los comandos de shell debajo.
  
Si va a ejecutar programas en scriptlets, ellos deben estar instalados antes de que los ejecute. Usted debe usar variantes especiales de la marca "Requires:" de tal forma que el programa sea instalado antes de que se intente usar. Estas son las formas "Requires(CONTEXTO):", e.g., "Requires(post)".
+
Si ejecuta cualquier programa dentro de los scriptlets, debe especificar los requisitos en la forma «<code>Requires(CONTEXTO)</code>» (por ejemplo <code>Requires(post)</code>).
  
La mayoría de los scriptlets (%pre, %post, %preun, y %postun) proveen un argumento que puede usar, accesible via $1, que es el número de paquetes de este nombre que será puesto en el sistema una vez que se complete la acción.
+
<code>%pre</code>, <code>%post</code>, <code>%preun</code>, y <code>%postun</code> ofrecen el argumento <code>$1</code>, que es el número de paquetes de este nombre que quedará en el sistema cuando la acción se complete. No comparar a la igualdad con <code>2</code>, pero en cambio comprobar si es mayor o igual a <code>2</code>. Para <code>%pretrans</code> y <code>%posttrans</code>, <code>$1</code> es siempre <code>0</code>.
 
 
No compare y pregunte por la igualdad a 2, pruebe si es mayor o igual que 2 ya que los usuarios se las pueden arreglar para tener múltiples versiones del paquete instalados simultáneamente. Para %pretrans y %posttrans, $1 es siempre 0.
 
 
 
Por ejemplo, después de agregar un manual info al sistema, el archivo dir que indexa los manuales info debería ser actualizado. Básicamente, después que instale el manual info, necesita ejecutar el programa install-info. Eso está bien, excepto que install-info es parte del paquete info y no hay garantía de que info esté instalado a menos que lo requiramos. Igualmente, si "install-info" falla, no queremos fallar todo el procesamiento. Abajo mostramos una forma de hacerlo:
 
  
 +
Por ejemplo, si el paquete instala un manual de información, entonces el índice del manual de información debe ser actualizado con <code>install-info</code> del paquete <code>info</code>. En primer lugar, no hay ninguna garantía de que el paquete <code>info</code> estará disponible a menos que lo declaremos explícitamente como necesario, y en segundo lugar, no queremos fracasar completamente si se produce un error en <code>install-info</code>:
 
  Requires(post): info
 
  Requires(post): info
 
  Requires(preun): info
 
  Requires(preun): info
Line 477: Line 507:
 
  fi
 
  fi
  
Otro habilitad tipo scriptlet son los triggers. Usted puede definir triggers (disparadores) para cuando otros paquetes son instalados o desinstalados. Vea Maximum RPM para más información acerca de los triggers o disparadores.
+
Hay otros fallos técnicos relacionados con la instalación de los manuales de información. El comando <code>install-info</code> actualizará el directorio de información, por lo que debemos eliminar el directorio inservible vacío de %{buildroot} durante la sección <code>%install</code>:
==== Macros ====
 
  
Los archivos spec pueden contener referencias a macros (textos que comienzan con "%"), que son remplazados con otros valores. Usted puede seguir % con una palabra, e.g., "%name", pero al igual que las variables shell usted debe ponerle llaves {...} si le siguen letras o dígitos justo después, e.g., "%{name}".
+
rm -f %{buildroot}%{_infodir}/dir
Como se menciona en Packaging Guidelines, hay dos estilos de referenciar algunos valores como rpm Build Root y las banderas de optimización:
 
* "estilo macro": %{buildroot}, %{optflags}
 
* "estilo variable": $RPM_BUILD_ROOT, $RPM_OPT_FLAGS
 
  
Escoja un estilo y úselo consistentemente cuando empaquete, este documento usa "estilo macro".
+
Otra capacidad tipo-scriptlet son los «triggers», que se pueden ejecutar con su paquete cuando otros paquetes sean instalados o desinstalados. Ver [http://rpm.org/api/4.4.2.2/triggers.html RPM Triggers].
  
Abajo una lista de macros típicos:
+
=== Macros ===
 +
 
 +
Las macros son texto en el formato de <code>%{string}</code>. Macros típicas:
  
 
{|
 
{|
!Macro !!Expansión !! Típica
+
! Macro !! Expansión típica !! Significado
|-
 
|%{_bindir} || /usr/bin ||
 
|-
 
|%{_builddir} ||~/rpmbuild/BUILD ||(directorio de construcción, vea %buildsubdir)
 
 
|-
 
|-
|%{buildroot} ||/var/tmp/... || buildroot, donde los archivos se "instalan" durante %install
+
| <code>%{_bindir}</code> || <code>/usr/bin</code> || Directorio binario: donde se almacenan normalmente los ejecutables.
 
 
 
|-
 
|-
|%{buildsubdir} ||/{name} || donde se compilan los archivos durante %build. Es bajo %{_builddir}, puesto después de %setup.
+
| <code>%{_builddir}</code> || <code>~/rpmbuild/BUILD</code> || Directorio de construcción: archivos que son compilados en un subdirectorio del directorio de construcción. Ver <code>%buildsubdir</code>.
 
|-
 
|-
|%{_datadir} ||/usr/share||
+
| <code>%{buildroot}</code> || <code>~/rpmbuild/BUILDROOT</code> || Raíz de construcción: donde los archivos son «instalados» durante la etapa de <code>%install</code>, que copia los archivos desde un subdirectorio de <code>%{_builddir}</code> a un subdirectorio de <code>%{buildroot}</code>. (Históricamente, <code>%{buildroot}</code> estaba en «/var/tmp/».)
 
|-
 
|-
|%{_defaultdocdir} ||/usr/share/doc||
+
| <code>%{buildsubdir}</code> || <code>%{_builddir}/%{name}</code> || Subdirectorio de construcción: un subdirectorio dentro de <code>%{_builddir}</code> donde se compilan los archivos durante la etapa de <code>%build</code>. Se establece después de <code>%setup</code>.
 
|-
 
|-
|%{dist} ||Distribución+nombre corto de versión (e.g., ".fc9")||
+
| <code>%{_datadir}</code> || <code>/usr/share</code> || Directorio compartido.
 
|-
 
|-
|%{fedora} ||Nómero de liberación fedora (e.g., 9)||
+
| <code>%{_defaultdocdir}</code> || <code>/usr/share/doc</code> || Directorio predeterminado de documentación.
 
|-
 
|-
|%{_includedir} ||/usr/include||
+
| <code>%{dist}</code> || <code>.fc''NUMERO''</code> || Distribución+nombre corto de versión (por ejemplo «<code>.fc9</code>»)
 
|-
 
|-
|%{_infodir} ||/usr/share/info||
+
| <code>%{fedora}</code> || <code>''NUMERO''</code> || Número de liberación de Fedora (por ejemplo «<code>9</code>»)
 
|-
 
|-
|%{_initrddir} ||/etc/rc.d/init.d||
+
| <code>%{_includedir}</code> || <code>/usr/include</code>
 
|-
 
|-
|%{_libdir} ||/usr/lib||
+
| <code>%{_infodir}</code> || <code>/usr/share/info</code>
 
|-
 
|-
|%{_libexecdir} ||/usr/libexec||
+
| <code>%{_initrddir}</code> || <code>/etc/rc.d/init.d</code>
 
|-
 
|-
|%{_localstatedir} ||/var||
+
| <code>%{_libdir}</code> || <code>/usr/lib</code>
 
|-
 
|-
|%{_mandir} ||/usr/share/man||
+
| <code>%{_libexecdir}</code> || <code>/usr/libexec</code>
 
|-
 
|-
|%{name} ||Nombre de paquete, definido por marca Name:||
+
| <code>%{_localstatedir}</code> || <code>/var</code>
 
|-
 
|-
|%{_sbindir} ||/usr/sbin||
+
| <code>%{_mandir}</code> || <code>/usr/share/man</code>
 
|-
 
|-
|%{_sharedstatedir} ||/usr/com||
+
| <code>%{name}</code> || || Nombre del paquete, definido por Name: etiqueta
 
|-
 
|-
|%{_sysconfdir} ||/etc||
+
| <code>%{_sbindir}</code> || <code>/usr/sbin</code>
 
|-
 
|-
|%{_sysconfdir} ||/etc||
+
| <code>%{_sharedstatedir}</code> || <code>/var/lib</code>
 
|-
 
|-
|%{version} ||Versión de paquete, definido por marca Version:||
+
| <code>%{_sysconfdir}</code> || <code>/etc</code>
 
|-
 
|-
 +
| <code>%{version}</code> || || Versión del paquete, definido por Version: etiqueta
 
|}
 
|}
Para más macros puede ver en /etc/rpm/* y los archivos "macros" bajo "/usr/lib/rpm/", especialmente /usr/lib/rpm/macros. También puede usar "rpm --showrc" para mostrar los valores que rpm utilizará para todas las opciones configuradas en los archivos rpmrc y archivos de configuración de macro.
 
  
Usted puede definir su propio conjunto de valores macro utilizando %define, asegúrese de definirlos antes de usarlos. Las definiciones de macro puede referenciar otros macros. Por ejemplo:
+
Aprenda más sobre las macros mirando en <code>/etc/rpm/*</code> y <code>/usr/lib/rpm</code>, especialmente <code>/usr/lib/rpm/macros</code>. También use <code>rpm --showrc</code> para mostrar los valores que RPM va a utilizar en las macros (modificados por los archivos de configuración de macros y <code>rpmrc</code>).
  
%define myvalue 50
+
Puede establecer sus propios valores de macro usando %global, pero asegúrese de definirlos antes de usarlos. (Las definiciones de macro pueden referirse a otras macros.) Por ejemplo:
 
+
%global date 2012-02-08
Usted puede usar rpmbuild para descubrir el valor de algún macro utilizando la opción "-E" (--eval). Por ejemplo, para ver la expansión de %{_bindir} en myfile.spec, usted puede ejecutar:
 
  
 +
Use la opción «<code>-E</code>» de <code>rpmbuild</code> para encontrar el valor de una macro en un archivo SPEC:
 
  rpmbuild -E '%{_bindir}' myfile.spec
 
  rpmbuild -E '%{_bindir}' myfile.spec
  
Packaging/RPMMacros tiene más información acerca de los macros, al igual que RPM Guide chapter 9.
+
Ver también [[Packaging/RPMMacros]] y [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s07.html Capítulo 9 de la guía RPM].
 
 
==== Otras marcas ====
 
  
Anotamos anteriormente las marcas "Requires" y "BuildRequires". Hay unas otras marcas más para controlar las dependencias: Provides, Obsoletes, Conflicts, y BuildConflicts.
+
=== Otras etiquetas ===
* "Provides:" le permite listar nombres de paquete virtual que este paquete provee. Algunas veces hay diferentes paquetes que pueden proveer la funcionalidad y usar paquetes (using packages) no importa cual. En ese caso (aclarar), cada uno de los paquetes que provee la funcionalidad deberían "proveer" un paquete virtual y entonces usando packages puede listar el nombre de paquete virtual bajo "Requires:". Por ejemplo, distintos paquetes puede proveer "latex", si usted depende del paquete virtual "tex(latex)", entonces los usuarios pueden escoger qué paquete obtener para obtener "latex" de él. Si usted provee paquetes virtuales, puede que tambien quiera usar sistema de alternativas , pero sea cuidadoso: los ajustes de las "alternativas" son a nivel del sistema, así que si múltiples usuarios en el mismo sistema quieren valores por omisión diferentes, no utilice este sistema. Usted puede encontrar lo que un paquete provee, tanto virtual como no-virtual, consultando "rpm -q --provides NOMBREDEPAQUETE". Algunos paquetes virtuales en Fedora son:
 
** ''MTA'' : Nombre usado para Mail Transport Agents, tal como Postfix.
 
** ''tex(latex)'' : Nombre usado para latex.
 
* "Obsoletes:" le permite declarar que instalando este paquete debería (normalmente) provocar la remoción de los otros paquetes nombrados. Esto es útil cuando un nombre de paquete cambia, o cuando un paquete remplaza completamente a un paquete diferente.
 
* "Conflicts:" le permite declarar cuáles paquetes no pueden ser instalados simultáneamente con este. Obviamente, intente evitar esto si puede, vea Packaging/Conflicts si cree que necesita usarlo.
 
* "BuildConflicts:" le permite declarar qué paquetes no pueden ser instalados cuando se construye este paquete. Obviamente, intente evitar esto si puede.
 
  
Usted puede controlar qué arquitecturas un paquete construye (o no construye). Por ejemplo, si su paquete no puede compilar en ppc, usted puede hacer:
+
Además de las etiquetas Requires y BuildRequires, también se pueden utilizar estas para controlar las dependencias:
 +
* '''Provides''': lista de nombres de paquetes virtuales que este paquete ofrece. Por ejemplo, puede haber un paquete «<code>foo</code>» que exige una funcionalidad «bar» particular de otro programa. Si hay varios paquetes que pueden satisfacer esa demanda, esos paquetes se pueden especificar «<code>Provides: bar</code>» y el paquete «<code>foo</code>» se puede especificar «<code>Requires: foo</code>». También puede utilizar el [http://dailypackage.fedorabook.com/index.php?/archives/6-Wednesday-Why-The-Alternatives-System.html sistema de «alternativas»], pero evitar si varios usuarios en el mismo sistema quieren diferentes valores predeterminados, ya que estos ajustes son para todo el sistema. Use «<code>rpm -q --provides NOMBREDEPAQUETE</code>» para ver lo que un determinado paquete proporciona. Algunos ejemplos de paquetes virtuales en Fedora:
 +
** MTA: Usado para el Agente de Transferencia de Correo, tal como sendmail.
 +
** tex(latex): Usado para latex.
 +
* '''Obsoletes''': eliminar los otros paquetes nombrados cuando estos paquetes sean instalados. Utilizar cuando cambia el nombre del paquete o cuando reemplaza totalmente a un paquete diferente.
 +
* '''Conflicts''': estado de otros paquetes que no se pueden instalar al mismo tiempo con éste. Evite esto si puede. Vea [[Packaging/Conflicts]].
 +
* '''BuildConflicts''': estado de los paquetes que no se pueden instalar en la construcción de éste paquete. Evite esto si puede.
  
 +
Para administrar arquitecturas diferentes, hay dos etiquetas:
 +
* '''ExcludeArch''': para excluir una arquitectura en la que el paquete no se construye. Por ejemplo:
 
  ExcludeArch: ppc
 
  ExcludeArch: ppc
 +
* '''ExclusiveArch''': para incluir sólo la arquitectura especificada. Evitar esto a menos que sea absolutamente correcto.
 +
Las arquitecturas válidas están listadas en [[Architectures|Arquitecturas]].
  
También existe la marca "ExclusiveArch". Las arquitecturas válidas que se pueden especificar en estas marcas están listadas en la sección Arquitecturas.
+
=== Subpaquetes ===
 
 
==== Subpaquetes ====
 
 
 
Un archivo spec puede definir más de un paquete binario, e.g., cliente y servidor, o paquetes runtime y developer. Si hay una gran cantidad de documentación, puede ser dividida en subpaquetes NOMBRE-doc. Usted siempre tendrá un archivo spec y un fuente RPM (SRPM), incluso si hay múltiples RPM binarios que ellos generan. Un archivo spec que produce múltiples paquetes binarios tiene aun así un único proceso de creación, así que existe secciones únicas %prep, %build, %check, e %install que crean todos los archivos para todos los paquetes.
 
 
 
En un archivo spec use la directiva %package para iniciar la definicón de un subpaquete:
 
 
 
%package sub_package_name
 
  
Por omisión, el nombre de subpaquete es PACKAGE_NAME, "-", SUBPACKAGE_NAME, usted puede utilizar "-n" para invalidar este comportamiento y construir un nuevo nombre:
+
Un archivo SPEC puede definir más de un paquete binario. En otras palabras, un archivo SRPM con un SPEC pueden resultar en varios RPMS. Tenga en cuenta que todavía hay sólo un proceso de creación (%prep, %build, %install, etc.). Los subpaquetes <code>name-doc</code> y <code>name-devel</code> son comunes para los archivos de documentación y desarrollo respectivamente.
  
  %package -n new_sub_package_name
+
Use la directiva <code>%package</code> para iniciar la definición de un subpaquete:
 +
  %package subpackage_name
  
Después de la directiva %package, liste las marcas (tags) para el subpaquete. Debería incluirse como mínimo las marcas "Summary:" y "Group:" y las directivas "%description SUBPACKAGE_NAME" y "%files SUBPACKAGE_NAME". Cualquier cosa no especificada por el subpaquete será heredado de su padre.
+
Después de cada directiva <code>%package</code>, liste las etiquetas para el subpaquete. Esta debe incluir por lo menos las etiquetas Summary y Group, así como las directivas <code>%description subpackage_name</code> y <code>%files subpackage_name</code>:
  
Para las directivas, si usó "-n" con %package, usted lo necesitará nuevamente para estas directivas. Usted necesita especificar el nombre para las otras directivas, e.g., %pre y %post, si las usa en el subpaquete.
+
Cualquier cosa no especificada por el subpaquete será heredado de su padre.
  
[http://docs.fedoraproject.org/drafts/rpm-guide-en/ch10s04.html Vea la sección acerca de subpaquetes de RPM Guide] para más información.
+
Por omisión, si el nombre del paquete es «<code>foo</code>» y el nombre del subpaquete es «<code>bar</code>», entonces el subpaquete resultante será «<code>foo-bar</code>». Usted puede anularlo con la opción «<code>-n</code>» (pero también tendrá que usarla en todas las demás directivas si la especifica aquí):
 +
%package -n new_subpackage_name
  
==== Condicionales ====
+
[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s04.html Vea la sección subpaquetes de la Guía RPM] para obtener más información.
  
Usted puede insertar declaraciones condicionales. Es decir, usted puede probar si está creando un binario para una arquitectura dada con:
+
=== Condicionales ===
  
 +
Puede insertar sentencias condicionales, por ejemplo para probar, si usted está creando un binario para una arquitectura determinada:
 
  %ifarch ARCHITECTURE_NAME
 
  %ifarch ARCHITECTURE_NAME
the negated version with:
+
la versión negada con:
 
  %ifnarch ARCHITECTURE_NAME
 
  %ifnarch ARCHITECTURE_NAME
 
+
o la condicional más general:
O la forma más general de condicional:
 
 
 
 
  %if TRUE_OR_FALSE
 
  %if TRUE_OR_FALSE
  
Opcionalmente existe una sección "%else", todas las seccciones se cierran con "%endif".
+
Hay una sección «<code>%else</code>» opcional; todos estas son cerradas con «<code>%endif</code>».
 
 
==== Lineamientos específicos de aplicación ====
 
Existen muchos lineamientos específicos a las aplicacioens que pueden ayudarle (e.g., para lenguajes de programación específicos, aplicaciones, librerías, y sistemas de construcción). Muchos de ellos se listan como parte de Application Specific Guidelines of Packaging/Guidelines. Ejemplos de lineamientos específicos a la aplicación son aquellos para :
 
* Cmake:https://fedoraproject.org/wiki/Packaging:Cmake
 
* Emacs:https://fedoraproject.org/wiki/Packaging:Emacs
 
  
De fallar eso, otras formas de encontrar ayuda específica a la aplicación son:
+
=== Lineamientos específicos de la aplicación ===
* El comando 'SEARCH' en Fedoraproject.org.
 
* PackagingDrafts:https://fedoraproject.org/wiki/PackagingDrafts
 
* Un Special Interest Group
 
* Páginas Wiki con prefijo 'Packaging'
 
  
==== Algunas otras pistas ====
+
Existen muchos lineamientos específicos de las aplicaciones que pueden ayudarle (por ejemplo, para lenguajes de programación específicos, aplicaciones, librerías y sistemas de construcción). Muchos de ellos están listados como parte de los [[Packaging/Guidelines#Application_Specific_Guidelines|Lineamientos específicos de la aplicación de empaquetamiento/directrices]]. Ejemplos de lineamientos específicos de la aplicación son aquellos para:
 +
* [[Packaging:Cmake|Cmake]]
 +
* [[Packaging:Emacs|Emacs]]
  
Si desea ver muchos ejemplos de scriptlets, usted puede mostrar todos los scriptlets de los programas instalados utilizando:
+
En su defecto, otras maneras de encontrar ayuda específica de la aplicación son:
 +
* El comando 'SEARCH' en Fedoraproject.org
 +
* [[PackagingDrafts]]
 +
* Un [[:Category:SIGs/es|Grupo de interés especial (SIG)]]
 +
* [[Special:PrefixIndex/Packaging|Páginas wiki con el prefijo 'Packaging']]
  
rpm -qa --queryformat "
+
=== Varios consejos ===
  
PACKAGE: %{name}
+
[[Packaging/FrequentlyMadeMistakes]] tiene información sobre errores cometidos con frecuencia. También hay algunas recomendaciones y trucos controversiales en [[PackageMaintainers/Packaging Tricks]].
" --scripts | less
 
  
La siguiente página tiene información acerca de los errores comunes que se cometen: [Packaging/FrequentlyMadeMistakes] .
+
Trate de escribir sus archivos SPEC para que pueda trabajar cuando se realice una nueva versión de desarrollo, sin cambios aparte de subir el número de versión y actualización de los archivos fuentes. Por ejemplo, si contiene archivos *.txt con bits de ejecución, en lugar de hacer
 +
  chmod a-x Filename1.txt Filename2.txt Filename3.txt
 +
considere hacer esto, lo que se encargará de los nuevos nombres de archivos que utilizan la misma convención de denominación de archivos:
 +
  chmod a-x *.txt
  
No intente interactuar con el usuario, RPM está diseñado para soportar instalaciones en modo lote (batch). Si una aplicación necesita mostrar un EULA, eso sería parte de la ejecución inicial, no de la instalación.
+
Si quiere ver muchos ejemplos de scriptlets, pueden verse todos los scriptlets de los programas instalados mediante:
 +
  rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less
  
Usted puede no querer iniciar ningún servicio, debido a que en una gran instalación eso puede frenar las cosas. Si instala un guión para init, considere usar chkconfig para arreglar que el servicio se arranque y detenga en el próximo reinicio del sistema. Antes de desinstalar usted debería normalmente intentar detener los servicios si están corriendo.
+
No intente interactuar con el usuario; RPM está diseñado para soportar instalaciones de procesamiento por lotes. Si una aplicación necesita mostrar una EULA, debe ser parte de la ejecución inicial, no de la instalación.
  
La desinstalación debería reversar la mayoría de los cambios hechos durante la instalación, pero no remueva ningún archivo creado por el usuario.
+
Usted podría no querer iniciar los servicios, ya que en una instalación grande podría retrasar las cosas. Si instala un script init o systemd, considere usar <code>chkconfig</code> o <code>systemctl</code> para organizar que el servicio sea iniciado/detenido en el siguiente reinicio. Antes de desinstalar, debería normalmente intentar detener los servicios si se están ejecutando.
  
Normalmente, si existen binarios ejecutables, un paquete separado "debug" se crea con los simbolos, y los simbolos son removidos de los paquetes normales binarios. Si esto no debiese ocurrir, usted puede deshabilitar la creación del paquete y remoción con:
+
La desinstalación debe revertir la mayoría de los cambios realizados durante la instalación, pero no eliminar los archivos creados por el usuario.
  
  %define _enable_debug_package 0
+
Normalmente, si hay ejecutables binarios, se eliminan los símbolos de depuración de los paquetes binarios normales y se colocan en un subpaquete <code>name-debug</code>. Si esto no sucede, puede deshabilitar la creación y remoción de este subpaquete poniendo esto en la parte superior de su SPEC:
  %define debug_package %{nil}
+
  %global _enable_debug_package 0
  %define __os_install_post /usr/lib/rpm/brp-compress %{nil}
+
  %global debug_package %{nil}
 +
  %global __os_install_post /usr/lib/rpm/brp-compress %{nil}
  
Una forma de verificar la versión de Fedora en un archivo spec para construcción condicional es:
+
Para evitar la remoción es posible que tenga que hacer esto en la sección <code>%install</code>:
 +
export DONT_STRIP=1
  
 +
Una forma de verificar la versión de Fedora en un archivo SPEC para la construcción condicional es:
 
  %if 0%{?fedora} <= <version>
 
  %if 0%{?fedora} <= <version>
 +
El <code>?</code> provoca que la macro evalúe ponerse en blanco si <code>%fedora</code> no está definida. Esto hace que el resultado final sea <code>0</code> (que es un número y por lo tanto aceptable), mientras que no interfiera con el resultado si hay realmente un valor para <code>%fedora</code>. (Tenga en cuenta que este truco no funciona en Koji «scratch» builds, donde <code>%fedora</code> se establece durante la creación del SRPM.)
  
El ? provoca que el macro evalúe a blanco si %fedora no está definido, y ello provoca que el resultado final sea "0", que es un número y en consecuencia aceptable, mientras que no interfiere con el resultado si de hecho hay un valor definido para %fedora.
+
Los programas de la GUI deben tener una entrada desktop para que la gente pueda invocarla desde el menú gráfico de escritorio. Para los archivos <code>.desktop</code>, consulte [[Packaging/Guidelines#Desktop_files|Lineamientos de empaquetado de Fedora para archivos desktop]] y [http://standards.freedesktop.org/desktop-entry-spec/latest/ entrada desktop en spec]. Para los iconos dentro de <code>/usr/share/icons</code>, consulte [http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html tema de ícono en spec].
 
 
Note que el truco anterior NO FUNCIONA en Koji "scratch" builds - %fedora es puesto durante la creación del fuente RPM. En consecuencia, este truco funciona en Koji ya que le sistema extrae las fuentes de los fuente RPM y reconstruye el fuente RPM con el valor apropiado de %fedora.
 
 
 
También existen algunas recomendaciones y trucos controversiales en [PackageMaintainers/Packaging_Tricks] .
 
  
Los programas GUI deben tener una entrada desktop (de tal forma que las personas puedan invocarla desde un menú gráfico). El desktop entry spec (para archivos .desktop) y icon theme spec definen cómo hacerlo (e.g., como usar /usr/share/icon).
+
== Construcción del paquete binario ==
Algunos documentos antiguos acerca de RPM tienen la mayor cantidad de información, pero algunos de estos documentos antiguos hacen algunas afirmaciones que ya no son ciertas:
 
  
* Los archivo rpm ya no son colocados en un directorio compartido /usr/src/redhat. Esta es una forma obsoleta de usar rpm y no es recomendada. Los sistemas modernos definen %{_topdir} en vez de ~/rpmbuild.
+
=== Prueba con rpmlint ===
* El proceso %install no instala archivos en su ubicación final. En cambio, "instala" los archivos en buildroot.
 
* El comando "rpm" ya no crea paquetes (e.g., "rpm -ba" fue alguna vez legal). Use el programa aparte "rpmbuild" para dichos propósitos.
 
  
==== Prueba rápida con rpmplint ====
+
Para detectar a tiempo muchos errores comunes, ejecute <code>rpmlint</code> en su archivo SPEC antes de intentar construir algo con él:
 +
$ rpmlint program.spec
 +
Si el error reportado no tiene sentido, ejecutarlo de nuevo con la opción «<code>-i</code>» para mensajes más largos.
  
Antes de intentar contruir nada, usted puede intentar ejecutar rpmlint sobre su archivo spec:
+
Trate de no tener errores, pero a veces <code>rpmlint</code> informa falsos positivos. Los [[Packaging/Guidelines#Use_rpmlint|Lineamientos de empaquetamiento de Fedora]] explica cuáles ignorar.
  
rpmlint program.spec
+
=== Crear un RPMS binario desde el archivo SPEC ===
  
Este programa atajará muchos errores de forma temprana. Si el error reportado no tiene sentido, ejecute nuevamente con la opción "-i" (esta opción ofrece mensajes de error más explicativos).
+
Una vez que haya creado su archivo SPEC, construir el SRPM y el RPMS binario ejecutando esto:
 +
$ rpmbuild -ba program.spec
  
Generalmente, usted no debería tener errores de rpmlint, pero algunas veces rpmlint es excesivamente ruidoso. Los lineamientos de empaquetamiento Fedora explican cuáles mensajes ignorar, e.g., ignore los erro"no-packager-tag" y "no-signature".
+
Si tiene éxito, RPMS se creará dentro de <code>~/rpmbuild/RPMS</code> y SRPMS dentro de <code>~/rpmbuild/SRPMS</code>.
  
Vale la pena revisar http://wiki.mandriva.com/es/Problemas_comunes_RpmLint para saber cómo ajustar el archivo spec en ciertas circunstancias.
+
Si no, vaya al directorio correspondiente y mire lo que queda. Para ayudar a depurar, puede saltarse las etapas anteriores que tuvieron éxito con la opción «<code>--short-circuit</code>». Por ejemplo, para reiniciar en la etapa de <code>%install</code> (saltando etapas anteriores), haga lo siguiente:
 
+
$ rpmbuild -bi --short-circuit program.spec
= Creando RPMs a partir del archivo spec =
 
 
 
Una vez que ha creado su archivo spec, digamos "programa.spec", usted puede crear los RPM fuente y binario simplemente corriendo:
 
 
 
$ rpmbuild -ba program.spec
 
 
 
Esto intentará ejecutar las siguientes etapas:
 
 
 
  1. Etapa %prep (preparación), que descomprime e instala los fuentes y parches en %_builddir (subdirectorio en ~/rpmbuild/BUILD).
 
  2. Etapa %build, que construye (e.g., compila) los archivos a ser instalados en %_buildir. Usualmente esto es algún equivalente a "make".
 
  3. Etapa install, que copia los archivos del directorio de construcción %_buildir (que estarí­a bajo ~/rpmbuild/BUILD) en el directorio buildroot, %{buildroot}. El directorio buildroot es definido por un previo "BuildRoot:", si lo deja a su valor normal que comienza con %{_tmppath}/{name}..., entonces el buildroot sería dentro de /var/tmp.
 
  4. Crea los RPM fuente y binario (archivos .rpm y .src.rpm). Los archivos binario RPM son creados utilizando la información de la lista %files.
 
 
 
Tenga cuidado: el "directorio de construcción" (donde ocurre la compilación durante %build) y la "raíz de construcción" (donde serán instalados los archivos durante %install) son diferentes .
 
 
 
Cuando las cosas salen mal, usted puede hacer "cd" al directorio apropiado y mirar que quedó allí. Si desea evitar etapas tempranas, use la opción "--short-circuit", esto es útil si ya tiene una construcción exitosa y un error en la sección %install. Por ejemplo, para reiniciar la etapa %install (saltando las etapas previas), haga lo siguiente:
 
 
 
  $ rpmbuild -bi --short-circuit program.spec
 
 
 
Si tiene éxito, encontrará sus RPMs bianrios en el subdirectorio "~/rpmbuild/RPMS/", y los fuente RPMs en "~/rpmbuild/SRPMS".
 
 
 
Si sólo desea crear el fuente RPM (.src.rpm), haga lo siguiente estando en el directorio SPECS:
 
  
 +
Si lo que desea es crear un SRPM (que no ejecuta la <code>%prep</code> o <code>%build</code> u otras etapas), ejecute esto:
 
  rpmbuild -bs program.spec
 
  rpmbuild -bs program.spec
  
Esto creará el fuente RPM en ~/rpmbuild/SRPMS. Crear solamente el fuente rpm (.src.rpm) es relativamente rápido porque rpm simplemente necesita copiar el archivo .spec y los SOURCES asociados en el archvio .src.rpm. Crear el rpm binario toma mucho más tiempo porque requiere que se ejecuten los guiones %prep, %build e %install.
+
=== Pruebas de RPMS binarios con rpmlint ===
  
= Probar los RPMs construídos =
+
<code>rpmlint</code> se puede ejecutar en archivos SPEC, RPMS y SRPMS para comprobar si hay errores. Es necesario para eliminar o corroborar las advertencias antes de publicar un paquete. Si usted está en el directorio SPECS, haga lo siguiente:
 
+
$ rpmlint ''NOMBRE''.spec ../RPMS/*/''NOMBRE''*.rpm ../SRPMS/''NOMBRE''*.rpm
Si usted hace "cd" al directorio "~/rpmbuild/RPMS", y luego cd al subdirectorio de la arquitectura especí­fica, encontrará algunos rpms binarios. Usted puede rápidamente ver sus archivos y permisos utilizando rpmls (verifique que sea lo que usted espera):
 
  
 +
Introduzca el directorio <code>~/rpmbuild/RPMS</code> en el subdirectorio de la arquitectura. Encontrará algunos RPMS binarios. Vea rápidamente sus archivos y permisos (para comprobar si son correctos) haciendo:
 
  $ rpmls *.rpm
 
  $ rpmls *.rpm
  
Ejecute rpmlint sobre el RPM "binario" (rpmlint trabaja sobre archivos .spec, RPMs binarios y RPMs fuentes, encontrando diferentes cosas en cada uno):
+
Si esto luce bien, instalarlos como root:
 
+
  # rpm -ivp package1.rpm package2.rpm package3.rpm ...
$ rpmlint *.rpm
 
 
 
Si esto luce bien, puede intentar convertirse en root e instalarlos:
 
 
 
  # rpm -ivp XYZ1.rpm XYZ2.rpm XYZ3.rpm ...
 
  
Luego puede probarlos. Si es una herramienta de lí­nea de comandos, puede invocarla sin necesidad de prefijar con /usr/bin? Si es una herramienta GUI, ¿se muestra en el menú? (si no, algo está mal con su entrada .desktop).
+
Pruebe los programas de diferentes maneras para ver si todo funciona correctamente. Si se trata de una herramienta de GUI, asegúrese de que aparece en el menú del escritorio, de lo contrario la entrada <code>.desktop</code> será errónea.
  
Luego puede desinstalarlos usando:
+
Desinstalar los paquetes más tarde haciendo:
 +
# rpm -e package1 package2 package3
  
# rpm -e XYZ1 XYZ2 XYZ3
+
== Mock y Koji ==
 
 
Si todo ello funciona, puede usar Mock para hacer prueba rigurosa de que usted tiene los requerimientos para construcción adecuados. Vea PackageMaintainers/MockTricks para más información acerca de cómo usar Mock, una vez que su cuenta sea miembro del grupo "mock", puede ejecutar comandos como el siguiente para realizar pruebas locales:
 
  
 +
[[Projects/Mock|Mock]] es una potente herramienta que utiliza el SRPM que usted ha creado para construir paquetes binarios dentro de un ambiente casi vacío. Esto puede revelar si tiene las dependencias de construcción adecuadas. Si esto falla, entonces se olvidó de incluir algo en BuildRequires. Consulte [[Using Mock to test package builds|Usando Mock para probar las construcciones de paquetes]]. Una vez que su cuenta sea miembro del grupo «<code>mock</code>», puede ejecutar comandos como este para hacer pruebas locales:
 
  $ mock -r fedora-9-i386 rebuild path_to_source_RPM
 
  $ mock -r fedora-9-i386 rebuild path_to_source_RPM
  
Una vez que Mock funcione en su sistema, puede usar Koji (que usa Mock) para hacer compilaciones en diferentes sistemas, algunos de los cuales usted puede que no tenga.
+
Puede utilizar Koji (que usa <code>mock</code>) para realizar construcciones en muchos sistemas diferentes, algunos de los cuales puede que no tenga. [[Join_the_package_collection_maintainers/es|PackageMaintainers/Join]] y [[PackageMaintainers/UsingKoji]] tienen más información acerca de Koji. Una vez que está instalado, puede probar su SRPM en una variedad de plataformas ejecutando comandos como:
Unirse_Mantenedores_de_Paquetes y PackageMaintainers/UsingKoji tienen más información acerca de Koji.
 
 
 
Una vez configurado, usted puede probar su RPM fuente en variedad de plataformas ejecutando comandos como el siguiente:
 
 
 
 
  $ koji build --scratch dist-f9 path_to_source_RPM
 
  $ koji build --scratch dist-f9 path_to_source_RPM
  
Uste puede sustituir dist-f9 por dist-f8, dist-f10, etc., para intentar construir para otras versiones. No use "dist-rawhide", ello no es realmente rawhide. Recuerde, los valores %fedora, %fc9, etc., no serán correctos para un "scratch build", así­ que no funcionarán si su archivo spec hace algo diferente basándose en esos valores.
+
Reemplace <code>dist-f9</code> con cualquier versión posterior de Fedora, pero no use <code>dist-rawhide</code>. Recuerde que los valores de <code>%fedora</code>, <code>%fc9</code> y así sucesivamente, no serán correctos para un scratch build, por lo que estos no funcionarán si el archivo SPEC hace algo diferente, basándose en esos valores.
 
 
Sus compilaciones koji sólo pueden depender de paquete de hecho están en el repositorio de la distribución OBJETIVO. En consecuencia, usted no puede usar koji para construir para distribuciones liberadas si su paquete depende de otros nuevos paquete que Bodhi no haya liberado aún. Usted "puede" usar koji para construir para rawhide (la próxima versión aún no liberada), incluso si depende de otros paquetes nuevos en la medida que los otros paquetes hayan sido construidos en la sección "devel" del CVS como se describe abajo.
 
 
 
Si necesita compilar versus un paquete que aún no está en una liberación estable, puede generar un ticket a rel-eng en: https://fedorahosted.org/rel-eng/newticket y solicitar que dicho paquete sea agregado como "buildroot override".
 
 
 
= Herramientas útiles =
 
 
 
El paquete "rpmdevtools" contiene una serie de herramientas útiles, "rpm -qil rpmdevtools" le mostrará qué es lo que instala. Una herramienta útil en particular es rpmdev-bumpspec que tiene la siguiente forma:
 
 
 
rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES
 
  
rpmdev-bumpspec resaltará la marca release en los archivos specs y agrega un comentario al changelog con el formato correcto de fecha/hora y versión. COMMENT tí­picamente deberí­a comenzar con "- ".
+
Sus construcciones Koji sólo pueden depender de los paquetes que se encuentran actualmente en el repositorio de distribución TARGET. En consecuencia, no puede construir con Koji para distribuciones liberadas si su paquete depende de otros paquetes nuevos que Bodhi no ha liberado todavía. Si necesita construir en contra de un paquete que no es todavía una liberación estable actualizada, puede presentar un ticket con rel-eng en: https://fedorahosted.org/rel-eng/newticket y solicitar que dicho paquete sea añadido como un buildroot override.
  
De forma simular "yum-utils" posee una serie de herramientas especí­ficas a yum. "yumdownloader" es especialmente útil, usted puede descargar el RPM fuente de un paquete simplemente ejecutando "yumdownloader --source NOMBREDEPAQUETE. Luego puede entonces usar "rpm -U NOMBREPAQUETEFUENTE" para instalar los archivos fuentes. E.G., "yumdownloader --source glib; rpm -Uvh glib*.src.rpm".
+
== Herramientas útiles ==
  
Puede que le sea útil RUST (GPL). Es un herramienta GUI para creación RPM "drag&drop" y también es una herramienta para crear cajas de pruebas (sandoxing) que le permite ejecutar instalaciones de software dentro de un entorno chrooted y automáticamente generar RPMs para código fuente arbitrario, sin siquiera ver el archivo spec.
+
El paquete <code>rpmdevtools</code> contiene una serie de herramientas útiles; «<code>rpm -qil rpmdevtools</code>» le mostrará lo que instala.
 +
* <code>rpmdev-bumpspec</code> : resalta la etiqueta de la versión en el archivo spec y añade un comentario en el registro de cambios con el formato de fecha y versión correctos:
 +
rpmdev-bumpspec --comment=COMENTARIO --userstring=NOMBRE+CORREOELECTRONICO_STRING SPECFILES
  
Si está creando archivos spec, puede ayudar el determinar %files. Note que, sin embargo, que ello no crea archivos spec, ni tampoco crea paquetes de calidad adecuada para los repositorios Fedora, es una herramienta principalmente para crear paquetes binarios RPM rápida y suciamente (Nota: ya no se encuentra más en "rusthq.com".)
+
El paquete <code>yum-utils</code> también tiene algunas herramientas útiles:
 +
* <code>yumdownloader</code> : descargar el SRPM del paquete ejecutando:
 +
yumdownloader --source NOMBREDEPAQUETE
  
Alien convierte entre formatos de paquetes. No producirá RPMs fuente limpios, pero convertir un paquete existente puede proveerle cierta información útil.
+
El paquete <code>auto-buildrequires</code> tiene un par de buenas herramientas para ayudar a descifrar las entradas de BuildRequires. Después de instalar este paquete, reemplace «<code>rpmbuild</code>» con «<code>auto-br-rpmbuild</code>» y verá una lista de BuildRequires generada automáticamente.
= Lineamientos y reglas =
 
  
Cuando usted cree sus paquetes, necesitará seguir las siguientes reglas y lineamientos:
+
Es posible que encuentre útil a [http://rust.sourceforge.net/ RUST] (GPL), aunque no crea archivos SPEC de la calidad adecuada para los paquetes de Fedora. [http://kitenet.net/~joey/code/alien/ Alien] convierte entre formatos de paquetes. No producirá SRPMS limpios, pero la conversión de un paquete existente podría proporcionar cierta información útil.
  
    * Unirse Mantenedores de Paquetes - describe el proceso para convertirse en un mantenedor de paquetes Fedora.
+
== Lineamientos y reglas ==
    * Packaging Guidelines
 
    * Package Naming Guidelines
 
    * Dist Tag Guidelines
 
    * Package Review Guidelines
 
  
Existen muchos guí­as oficiales de lineamientos que le ayudarán con sus circunstancias especí­ficas (programas Java programs, programas OCaml, programas GNOME, etc.), el Packaging Guidelines incluye una referencia cruzada a dichas guí­as. También puede aprender a partir de las secciones SIGs y Package Maintainers. También puede ver la lista completa de páginas Wiki acerca de Empaquetamiento para ver si alguna aplica a su circunstancia.
+
Al crear los paquetes, deberá seguir las siguientes reglas y lineamientos:
 +
* [[Join the package collection maintainers/es|Cómo unirse a los Mantenedores de la colección de paquetes de Fedora]]
 +
* [[Packaging:Guidelines|Lineamientos de empaquetamiento]]
 +
* [[Packaging:NamingGuidelines|Lineamientos de nombrado de paquetes]]
 +
* [[Packaging:LicensingGuidelines|Lineamientos de licenciamiento de paquetes]]
 +
* [[Packaging:DistTag|Lineamientos de la etiqueta Dist]]
 +
* [[Packaging:ReviewGuidelines|Lineamientos de revisión de paquetes]]
  
En caso de que ello falle, puede encontrar recomendaciones útiles en los borradores no oficiales Packaging Drafts y Packaging Drafts To Do. Obviamente estos no son oficiales. Puede encontrar algunas ideas a partir de SuSE , Debian , pero recuerde las distribuciones difieren en sus reglas , así­ que no presuma que pueden ser utilizadas directamente.
+
Hay muchas pautas oficiales que le ayudarán con circunstancias específicas (por ejemplo, programas Java, OCaml, GNOME, etc.). Puede aprender más desde las secciones [[:Category:SIGs/es|SIGs]] y [[:Category:Package Maintainers/es|Maintenedores de paquetes]]. [[Special:Prefixindex/Packaging|También puede ver la lista de todas las páginas Wiki sobre el empaquetamiento]] para ver si alguna es aplicable.
  
Los archivos .spec que usted cree deben ser igualmente de código libre, como se nota en el CLA.
+
En su defecto, puede que encuentre algunas recomendaciones útiles en los [[Special:Search?ns0=1&search=PackagingDrafts%2F&searchx=Search|Borradores de empaquetamiento]] no oficiales y en [[PackagingDrafts|Borradores de empaquetamiento para hacer]].
  
= Mantenimiento de paquetes =
+
== Mantenimiento del paquete ==
  
Una vez que su paquete sea aceptado, usted, o sus comantenedores, deben mantenerlo. Vea el Package update HOWTO y el Package update guidelines para más información.
+
Una vez que su paquete ha sido aceptado, usted y sus co-mantenedores tendrán que mantenerlo. Ver [[Package update HOWTO|CÓMO actualizar paquetes]] y [[Package update guidelines|Lineamientos de actualización de paquetes]]. Si actualiza la versión en varias liberaciones de Fedora, hágalo hacia atrás en el tiempo (por ejemplo, libere para Fedora N, luego una vez aceptado, Fedora N-1). El sistema presume que las versiones más recientes de Fedora poseen la misma o más recientes versiones de los programas.
  
Si usted actualiza la versión en múltiples liberaciones de Fedora, hágalo "hacia atrás" en el tiempo, e.g., libere para Fedora N, luego, una vez aceptado, Fedora N-1 (el sistema presume que las versiones mas recientes de Fedora poseen la misma o más recientes versiones de programas).
+
Alentar a los desarrolladores principales a utilizar las convenciones estándar en la liberación del código fuente. Usando las convenciones estándar hace que el empaquetamiento sea mucho más fácil. Para obtener más información, consulte:
 +
* [http://www.dwheeler.com/essays/releasing-floss-software.html Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation] (un resumen rápido)
 +
* [http://www.gnu.org/prep/standards/html_node/Managing-Releases.html GNU Coding Standards release process]
 +
* [http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO]
 +
* [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard (FHS)]
 +
* [http://offog.org/articles/packaging/ Packaging Unix software]
  
= Para más información =
+
== Para obtener más información ==
  
La página Package Maintainers enlaza a muchas otras páginas útiles y Updating Package HOWTO describe como actualizar un paquete existente que ya usted mantiene en Fedora.
+
La página [[:Category:Package Maintainers/es|Mantenedores de paquetes]] enlaza a muchas otras páginas de interés, y [[Package update HOWTO|CÓMO actualizar paquetes]] describe cómo actualizar un paquete existente que usted ya mantenga en Fedora.
  
Para más información, fuera de este sitio, y del Wiki de Fedora, vea:
+
Para obtener más información, fuera de la Wiki de Fedora, consulte:
 +
* [http://www.g-loaded.eu/2006/04/05/how-to-build-rpm-packages-on-fedora/ How to build RPM packages on Fedora] - muy breve repaso
 +
* Empaquetado de software con RPM (developerWorks) [http://www.ibm.com/developerworks/ssa/linux/library/l-rpm1/ Part 1], [http://www.ibm.com/developerworks/ssa/linux/library/l-rpm2/ Part 2], y [http://www.ibm.com/developerworks/ssa/linux/library/l-rpm3/ Part 3]
 +
* Fedora Classroom tuvo una sesión de IRC en empaquetamiento y puede consultar los registros en https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29
 +
* [http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html Fedora Packager's Handbook]
 +
* [http://www.redhatmagazine.com/2008/02/28/when-sally-met-eddie-the-fedora-package-story/ When Sally met Eddie] - un cuento simple, pero pocos detalles
 +
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM Book] - información más completa, pero en algunos casos antigua/obsoleta
 +
* [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html RPM Guide, section on creating RPMs] - esta tiene un montón de buena información y es un poco más actualizada, pero es un proyecto
 +
* [http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html Developer's guide, section on building RPMs]
 +
* [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Creating RPMS slides] de Guru Labs
 +
* [http://freshrpms.net/docs/fight/ The fight, my first attempt to make a readable rpm package building introduction.]
 +
* [http://www-uxsup.csx.cam.ac.uk/talks/rpmbuild/rpmbuild.pdf Cambridge RPM tutorial] es una presentación sobre la creación de RPM básicos
 +
* [http://en.tldp.org/HOWTO/RPM-HOWTO/index.html RPM HOWTO: RPM at Idle by Donnie Barnes]
 +
* [http://home.fnal.gov/~dawson/rpms/howto/index.html RPM HowTo by Dawson]
 +
* [http://en.opensuse.org/Build_Service/cross_distribution_package_how_to Cross-distribution package HOWTO] tiene consejos si usted está construyendo un RPM para muchas distribuciones.
 +
* [http://wiki.mandriva.com/en/Development/Howto/RPM Mandriva Rpm HowTo (en)] es un tutorial de RPM, aunque para Mandriva (no Mandrake). Nota: En Fedora, ''no'' no recomprimir los archivos tarballs originales, como sugiere Mandriva, porque cambiaría sus hashes criptográficos.
 +
* [http://linuxshellaccount.blogspot.com/2008/03/creating-your-own-linux-rpms-initial.html Creating Your Own Linux RPM's - The Initial Software Build] es otra breve introducción, pero señala que «El proceso de construcción de RPM es mucho más sencillo que la creación de paquetes para Solaris... Menos pasos, y la posibilidad de agregar toda la información de su software en un archivo de especificación, haciendo algo más compacto (y más fácil de modificar o reproducir) el sistema de empaquetamiento de software».
 +
* [http://fedoranews.org/alex/tutorial/rpm/ All you need to know about RPM] (más sobre la instalación de paquetes que de crearlos)
 +
* La [http://wiki.rpm.org/ Wiki de rpm.org] tiene algunas informaciones útiles, tal como la [http://wiki.rpm.org/Problems lista de problemas RPM conocidos]
  
    * How to build RPM packages on Fedora - vistazo breve
+
Nota: El sitio [http://rpm5.org/ rpm5.org] tiene alguna documentación, pero no depende de él; que es la página de un ''fork'' de RPM mantenido por Jeff Johnson. El RPM utilizado por Fedora (y Novell/SuSE) se basa más bien en [http://www.rpm.org rpm.org].
    * Packaging software with RPM (developerWorks) Part 1 , Part 2 y Part 3 .
+
[http://lwn.net/Articles/236029/ lwn.net tiene un breve artículo] acerca de esto.
    * Fedora Packager's Handbook
 
    * When Sally met Eddie - un cuento simple, pero poco detalle.
 
    * Maximum RPM Book - la información más completa, pero en algunos casos, antigua/obsoleta.
 
    * RPM Guide, sección creando RPMs - esto tiene mucha buena información y es ligeramente más actualizada, pero es un borrador.
 
    * Developer's guide, section on building RPMs .
 
    * Creating RPMS slides de Guru Labs.
 
    * The fight, my first attempt to make a readable rpm package building introduction .
 
    * RPM Tutorial .
 
    * RPM HOWTO: RPM at Idle by Donnie Barnes .
 
    * RPM HowTo por Dawson.
 
    * SuSE build tutorial - es acerca de SuSE, no Fedora. Cross-distribution package HOWTO tiene algunas pistas si está creando un RPM para varias distribuciones.
 
    * Mandriva Rpm HowTo (alt ) es un tutorial RPM, para Mandriva (Mandrake). Nota: En Fedora no se recomprime los tarballs originales, como Mandriva sugiere porque ello cambiarí­a sus hash criptográficos.
 
    * Creating Your Own Linux RPM's - The Initial Software Build es otra introducción breve, pero anota acerca de que el proceso de construir RPMs es mucho más simple que crear paquetes para Solaris, menos pasos, y tiene la habilidad de agregar toda la información del software en un único archivo haciendo el proceso algo más compacto y fácil de modificar o reproducir para el caso del sistema de empaquetamiento de software.
 
    * All you need to know about RPM - más acerca de instalación de paquetes que acerca de crear paquetes.
 
    * El Wiki de rpm.org Wiki tiene algunas informaciones útiles, tal como la lista de problemas RPM conocidos .
 
  
Nota: El sitio de rpm5.org tien algo de documentación pero no dependa de ella, ese es el sitio del "fork" de RPM mantenido por Jeff Johnson. El RPM utilizado por Fedora y Novell/SuSE, está basado en rpm.org rpm.org. lwn.net tiene un breve artí­culo al respecto.
+
[[Category:How to]]
 +
[[Category:Package Maintainers]]
 +
[[Category:Spanish translations]]

Latest revision as of 20:59, 19 September 2016

Introducción

Esta página describe detalladamente cómo crear un paquete RPM y en particular, cómo crear un archivo SPEC. A diferencia de otras guías RPM, esta página explica los detalles de Fedora con enlaces a los lineamientos específicos de Fedora. Dado que es mantenida a través de la Wiki de Fedora, es probable que esté más al día que otras guías. A pesar del enfoque en Fedora, la mayor parte de este documento se aplica a otras distribuciones basadas en RPM. Si está impaciente, puede comenzar por mirar el más breve Cómo crear un paquete RPM GNU Hola.

Tenga en cuenta que estos no son los lineamientos del paquete oficial de Fedora, que puede verse en los Lineamientos de empaquetado y Lineamientos de nombrado de paquetes. Dicho esto, esta página debe ser compatible con ellos.

Si va a crear un paquete RPM para el repositorio de Fedora, siga el procedimiento para unirse a los mantenedores de la colección de paquetes.

Preparando su sistema

Antes de crear paquetes RPM en Fedora, necesita instalar algunas herramientas básicas de desarrollo y configurar la(s) cuenta(s) que va a utilizar:

# yum install @development-tools
# yum install fedora-packager

Puede crear un usuario ficticio (dummy) específicamente para crear paquetes RPM por si el proceso de construcción sale mal no podrá destruir sus archivos o enviar sus claves privadas al mundo.

Stop (medium size).png
Usted nunca debe crear los paquetes como usuario root.

Crear un nuevo usuario con el nombre makerpm, agregar el usuario al grupo 'mock', establecer una contraseña e ingresar como usuario:

# /usr/sbin/useradd makerpm
# usermod -a -G mock makerpm
# passwd makerpm

Una vez que ha iniciado la sesión como un usuario build/dummy, crear la estructura de directorios necesaria en su directorio home ejecutando:

$ rpmdev-setuptree

El programa rpmdev-setuptree creará el directorio ~/rpmbuild y una serie de subdirectorios (por ejemplo SPECS y BUILD), que va a usar para crear sus paquetes. También se crea el archivo ~/.rpmmacros, que puede utilizarse para configurar diversas opciones.

Los lineamientos de empaquetado recomiendan preservar los datos del archivo; usted puede hacer esto automáticamente si usa wget o curl para obtener los archivos fuentes. Si utiliza wget para obtener los archivos fuentes, añada el texto «timestamping = on» a ~/.wgetrc. Si usa curl, agregue el texto «-R» a ~/.curlrc.

Normalmente, no necesitará volver a realizar estos pasos.

Los fundamentos de la construcción de paquetes RPM

Para crear un paquete RPM, necesitará crear un archivo de texto «.spec» que suministre la información acerca del software que será empaquetado. Luego podrá ejecutar el comando rpmbuild sobre dicho archivo SPEC, lo que provocará ejecutar una serie de pasos para producir sus paquetes.

Normalmente, deberá colocar sus fuentes originales (prístina), archivos tales como .tar.gz provistos por los desarrolladores originales, en el directorio ~/rpmbuild/SOURCES. deberá colocar su archivo .spec en el directorio ~/rpmbuild/SPECS y asignarle el nombre «NOMBRE.spec», donde NOMBRE es el nombre base del paquete. Para crear ambos paquetes, tanto el binario como el fuente, cambie al directorio ~/rpmbuild/SPECS y ejecute:

$ rpmbuild -ba NOMBRE.spec

Cuando rpmbuild es invocado de esta manera, leerá el archivo .spec y recorrerá en orden las etapas listadas a continuación. Los nombres que comienzan con % son macros predefinidas (vea la siguiente tabla).

Etapa Lee Escribe Acción
%prep %_sourcedir %_builddir Esta lee los archivos fuentes y parches en el directorio de fuentes %_sourcedir. Se desempaquetan los archivos fuentes al subdirectorio dentro del directorio de construcción %_builddir y se aplican los parches.
%build %_builddir %_builddir Esta compila los archivos dentro del directorio de construcción %_builddir. Esto se hace a menudo implementando alguna variación de «./configure && make».
%check %_builddir %_builddir Verifica que el software funciona correctamente. Esto es usualmente implementado ejecutando alguna variación de «make test». Muchos paquetes no implementan esta etapa.
%install %_builddir %_buildrootdir Esta lee los archivos dentro del directorio de construcción %_builddir y escribe a un directorio dentro del directorio raíz de construcción %_buildrootdir. Los archivos que son escritos son los que se supone serán instalados cuando el paquete binario sea instalado por el usuario final. Tenga cuidado con esta terminología algo extraña: El directorio raíz de construcción no es lo mismo que el directorio de construcción. Esta etapa usualmente se implementa ejecutando «make install».
bin %_buildrootdir %_rpmdir Este lee los archivos dentro del directorio raíz de construcción %_buildrootdir para crear los paquetes RPM binarios dentro del directorio RPM %_rpmdir. Adentro del directorio RPM hay un directorio para cada arquitectura, y un directorio "noarch" para los paquetes que se aplican a cualquier arquitectura. Estos archivos RPM son los paquetes para que instalen los usuarios.
src %_sourcedir %_srcrpmdir Este crea un paquete fuente RPM (.src.rpm) dentro del directorio fuente RPM %_srcrpmdir. Estos archivos son necesarios para revisar y actualizar los paquetes.


Como podrá notar, algunos directorios tienen ciertos propósitos específicos en rpmbuild. Estos son:

Nombre de la macro Nombre Usualmente Propósito
%_specdir Directorio de especificación ~/rpmbuild/SPECS Archivos de especificaciones RPM (.spec).
%_sourcedir Directorio fuente ~/rpmbuild/SOURCES Paquete fuente prístina (por ejemplo, tarballs) y parches.
%_builddir Directorio de construcción ~/rpmbuild/BUILD Los archivos fuentes son desempaquetados y compilados en un subdirectorio dentro de este.
%_buildrootdir Directorio raíz de construcción ~/rpmbuild/BUILDROOT Los archivos son instalados bajo este directorio durante la etapa %install.
%_rpmdir Directorio RPM binario ~/rpmbuild/RPMS Los RPM binarios son creados y almacenados bajo este directorio.
%_srcrpmdir Directorio RPM fuente ~/rpmbuild/SRPMS Los RPM fuente son creados y almacenados bajo este directorio.

Si falla alguna etapa, tendrá que revisar la salida para ver por qué falló y deberá cambiar el archivo .spec (u otra entrada) cuando sea necesario.

Preparándose a empaquetar un programa específico

Si se requieren programas especiales para construir o ejecutar el programa que está empaquetando, instale dichos programas y anote los que son.

Al empaquetar un programa para el repositorio de Fedora, debe empaquetar los fuentes prístina (originales), junto a los parches y las instrucciones de construcción; en general no es aceptable comenzar con un código precompilado. Instale el archivo con la fuente original (usualmente un archivo .tar.gz) en el directorio ~/rpmbuild/SOURCES (de la cuenta de usuario para construcción de RPM).

Lea el manual de instrucciones para la instalación de su programa. A menudo es una buena idea hacer un «simulacro» construyendo manualmente el programa antes de intentar hacerlo a través de RPM. Con unas pocas excepciones, todos los binarios y librerías incluidas en los paquetes de Fedora deben construirse desde el código fuente que se incluye en el paquete fuente.

Dividir el programa

El código fuente de la aplicación es a menudo liberado con el código fuente de otras librerías externas «incluido» en ellos. No junte librerías externas con la aplicación principal en un solo paquete. En cambio, divídelos en paquetes separados.

Concesión de licencias

Sólo empaquete software que sea legal en su paquete. Ver Packaging:Guidelines#Legal, Licensing:Main y Packaging:LicensingGuidelines. En general, sólo empaquete software que sea lanzado como software de código abierto (OSS) utilizando una licencia OSS aprobada (tales como las licencias GPL, LGPL, BSD-new, MIT/X, o Apache 2.0). Asegúrese de que el software realmente tiene licencia de esta manera (por ejemplo, verificar in situ los encabezados del código fuente, archivos README, etc.). Si hay librerías incluidas, asegúrese de que también son OSS.

Reutilizar la información del paquete existente

Trate de reutilizar lo que se pueda. Obviamente, asegúrese de que no está empaquetando algo que ya ha sido empaquetado. Encontrará una lista de los paquetes existentes en la Colección de paquetes de Fedora en la Base de datos de paquetes de Fedora. Compruebe también las Solicitudes de revisión en progreso y la lista de Paquetes retirados. Puede utilizar los Repositorios de paquetes Git de Fedora directamente para ver los archivos SPEC (y parches). Puede descargar los SRPMS utilizando un programa desde el paquete yum-utils:

$ yum -y install yum-utils
$ yumdownloader --source nombre-paquetefuente

Alternativamente, puede obtener el código fuente manualmente desde la página http/ftp de un espejo de Fedora dentro del directorio releases/34/Everything/source/SRPMS. Reemplace «34» con la versión de Fedora que desee y descargue el paquete .src.rpm que necesita.

Una vez que tiene el SRPM, instalarlo en ~/rpmbuild:

$ rpm -ivh nombre-paquetefuente*.src.rpm

También puede desempaquetar el SRPM en un directorio usando rpm2cpio:

$ mkdir NOMBREDEPROGRAMA_src_rpm
$ cd NOMBREDEPROGRAMA_src_rpm
$ rpm2cpio ../NOMBREDEPROGRAMA-*.src.rpm | cpio -i

Algunas veces es más fácil comenzar con un paquete existente y luego limpiarlo y prepararlo para Fedora. RPM Find puede ayudarle a encontrar RPM para sistemas diferentes a Fedora. Puede instalar SRPMS de otros sistemas de la misma forma que para los de Fedora. Si eso falla, puede localizar los archivos de paquetes fuentes (no los binarios .deb) en Ubuntu o Debian (los archivos de paquetes fuentes son tarballs estándar con un subdirectorio «debian/»). Si la colección de ports FreeBSD lo tiene, podrí­a descargarlo del FreeBSD ports tarball y ver si la información de empaquetado existente le ayuda como punto de partida. Sin embargo, esto a veces no es útil para todos. Las diferentes distribuciones tienen diferentes reglas y lo que hacen en algunos casos puede ser inapropiado para Fedora.

Creando un archivo SPEC

Ahora necesita crear un archivo SPEC en el directorio ~/rpmbuild/SPECS. Debería nombrarlo de acuerdo al nombre del programa (por ejemplo «program.spec»). Use donde se pueda el nombre de archivo o el nombre publicado por el autor del software, pero asegúrese de seguir los Lineamientos de nombres de paquetes.

Plantillas de SPEC

Al crear un archivo SPEC por primera vez, vim o emacs crearán automáticamente una plantilla para usted:

 $ cd ~/rpmbuild/SPECS
 $ vim program.spec

He aquí un ejemplo de lo que se verá como plantilla (Nota: la plantilla que se ofrece no necesariamente cumple con los Lineamientos de empaquetado de Fedora):

Name:		
Version:	
Release:	1%{?dist}
Summary:	
Group:		
License:	
URL:		
Source0:	
BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires:	
Requires:	

%description

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root,-)
%doc

%changelog

Puede usar $RPM_BUILD_ROOT en lugar de %{buildroot}. Ambos son aceptables, pero sólo para ser más consistente.

También puede usar el comando rpmdev-newspec para crear un archivo SPEC para usted. rpmdev-newspec NOMBRE-DE-NUEVO-PAQUETE puede crear un archivo SPEC inicial para un nuevo paquete, adaptado a varios tipos de paquetes. Adivinará también qué tipo de plantilla utilizar basándose en el nombre del paquete, o puede especificarle una plantilla en particular. Vea las plantillas disponibles en /etc/rpmdevtools/spectemplate-*.spec, y consulte rpmdev-newspec --help para más información. Por ejemplo, para crear un nuevo archivo SPEC para un módulo python:

cd ~/rpmbuild/SPECS
rpmdev-newspec python-antigravity
vi python-antigravity.spec

Ejemplo de SPEC

He aquí un ejemplo simple que muestra un archivo SPEC de Fedora 16 para el programa eject:

Summary:            A program that ejects removable media using software control
Name:               eject
Version:            2.1.5
Release:            21%{?dist}
License:            GPLv2+
Group:              System Environment/Base
Source:             %{name}-%{version}.tar.gz
Patch1:             eject-2.1.1-verbose.patch
Patch2:             eject-timeout.patch
Patch3:             eject-2.1.5-opendevice.patch
Patch4:             eject-2.1.5-spaces.patch
Patch5:             eject-2.1.5-lock.patch
Patch6:             eject-2.1.5-umount.patch
URL:                http://www.pobox.com/~tranter
ExcludeArch:        s390 s390x
BuildRequires:      gettext
BuildRequires:      libtool

%description
The eject program allows the user to eject removable media (typically
CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software
control. Eject can also control some multi-disk CD changers and even
some devices' auto-eject features.

Install eject if you'd like to eject removable media using software
control.

%prep
%setup -q -n %{name}
%patch1 -p1
%patch2 -p1
%patch3 -p1
%patch4 -p1
%patch5 -p1
%patch6 -p1

%build
%configure
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install

install -m 755 -d %{buildroot}/%{_sbindir}
ln -s ../bin/eject %{buildroot}/%{_sbindir}

%find_lang %{name}

%files -f %{name}.lang
%doc README TODO COPYING ChangeLog
%{_bindir}/*
%{_sbindir}/*
%{_mandir}/man1/*

%changelog
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 2.1.5-21
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild

* Fri Jul 02 2010 Kamil Dudka <kdudka@redhat.com> 2.1.5-20
- handle multi-partition devices with spaces in mount points properly (#608502)

Resumen del archivo SPEC

Otras guías útiles:

Usted deberá seguir los lineamientos Fedora: Lineamientos de nombres de paquetes, Lineamientos de empaquetado, y Lineamientos de revisión de paquetes.

Insertar los comentarios con el primer carácter «#», pero evite las macros (comienzan con %) que sean potencialmente multilíneas (las que se expanden primero). Si está comentando una línea, doble los signos de porcentaje (%%). Evite también los comentarios inline en la misma línea como un comando de script.

Las principales etiquetas se enumeran a continuación. Tenga en cuenta que las macros %{name}, %{version} y %{release} pueden utilizarse para hacer referencia a las etiquetas Name, Version y Release respectivamente. Cuando cambia la etiqueta, las macros se actualizan automáticamente para utilizar el nuevo valor.

  • Name: El nombre (base) del paquete, que debe coincidir con el nombre del archivo SPEC. Debe seguir los Lineamientos de nombres de paquetes y generalmente estar en minúsculas.
  • Version: El número de versión de desarrollo. Vea la Sección etiqueta de versión en los lineamientos de empaquetado. Si la versión contiene etiquetas que no son numéricas (contiene etiquetas que no son números), puede que necesite incluir caracteres no numéricos adicionales en la etiqueta Release. Si el desarrollo utiliza fechas completas para distinguir las versiones, considere usar números de versión con la forma yy.mm[dd] (por ejemplo 2008-05-01 se convierte en 8.05).
  • Release: El valor inicial normalmente debería ser 1%{?dist}. Incremente el número cada vez que libere un nuevo paquete para la misma versión de software. Cuando una nueva versión de desarrollo es liberada, cambiar la etiqueta Version para igualar y restablecer el número de Release a 1. Vea la Sección etiqueta de versión en los lineamientos de empaquetado. La etiqueta opcional Dist podría ser útil.
  • Summary: Un breve, sumario del paquete en una línea. Use inglés americano. Y no termine con un punto.
  • Group: Este tiene que ser un grupo pre-existente, como «Applications/Engineering»; ejecute «less /usr/share/doc/rpm-*/GROUPS» para ver la lista completa. Use el grupo «Documentation» para los sub-paquetes (por ejemplo kernel-doc) que contienen documentación. Nota: Esta etiqueta está en desuso desde Fedora 17. Consulte Preámbulo de referencia del archivo Spec
  • License: La licencia, debe ser una licencia de software de código abierto. No usar la antigua etiqueta Copyright. Utilizar una abreviatura estándar (por ejemplo «GPLv2+») y ser específico (por ejemplo use «GPLv2+» para la GPL versión 2 o superior en lugar de simplemente «GPL» o «GPLv2» cuando sea cierto). Consulte Licensing y los Lineamientos de licencias. Usted puede listar múltiples licencias combinándolas con «and» y «or» (por ejemplo «GPLv2 and BSD»).
  • URL: La dirección URL completa para obtener más información sobre el programa (por ejemplo, la página web del proyecto). Nota: Esta no es de donde proviene el código fuente original que sirve para la etiqueta Source0 de abajo.
  • Source0: La dirección URL completa para el archivo comprimido que contiene el código fuente (original) prístina, liberado como desarrollo. «Source» es sinónimo de «Source0». Si usted da una dirección URL completa (y debería), su nombre base será utilizado cuando se busque en el directorio SOURCES. Si es posible, insertar %{name} y %{version}, así los cambios en cualquiera de ellas irá al lugar adecuado. Preservar los datos al descargar archivos fuentes. Si existe más de un archivo fuente, nómbrelos como Source1, Source2 y así sucesivamente. Si va a añadir nuevos archivos completos, además de las fuentes originales, lístelos como fuentes después de las fuentes prístinas. Una copia de cada una de estas fuentes serán incluídas en cualquier SRPM que cree, a menos que específicamente le indique lo contrario. Vea Source URL para obtener más información sobre los casos especiales (por ejemplo, control de revisión).
  • Patch0: El nombre del primer parche para aplicar al código fuente. Si necesita parchear los archivos después de que hayan sido descomprimidos, debe editar los archivos y guardar sus diferencias como un archivo «patch» en su directorio ~/rpmbuild/SOURCES. Los parches deben hacer sólo un cambio lógico cada uno, así que es muy posible tener varios archivos de parches.
  • BuildArch: Si está empaquetando archivos que son independientes de la arquitectura (por ejemplo, scripts de shell, archivos de datos), agregar «BuildArch: noarch». La arquitectura para el RPM binario será entonces «noarch».
  • BuildRoot: Esta es dónde los archivos serán «instalados» durante el proceso %install (después del proceso %build). Esta es ahora redundante en Fedora y sólo es necesaria para EPEL5. De forma predeterminada, la raíz de construcción se coloca en «%{_topdir}/BUILDROOT/».
  • BuildRequires: Una lista separada por comas de paquetes requeridos para la construcción (compilar) del programa. Este campo se puede (y lo es comúnmente) repetir en varias líneas. Estas dependencias no son determinadas automáticamente, usted debe incluir todo lo necesario para construir el programa. Algunos paquetes comunes se pueden omitir, tal como gcc. Puede especificar una versión mínima si es necesario (por ejemplo «ocaml >= 3.08»). Si necesita el archivo /EGGS, determinar el paquete que lo posee mediante la ejecución de «rpm -qf /EGGS». Si necesita el programa EGGS, determinar el paquete que lo posee mediante la ejecución de «rpm -qf which EGGS». Mantener las dependencias al mínimo (por ejemplo use sed en vez de perl si realmente no necesita las capacidades de perl), pero tenga en cuenta que algunas aplicaciones desactivan funciones permanentemente si la dependencia asociada no está presente; en estos casos deberá incluir los paquetes adicionales. El paquete Package-x-generic-16.pngauto-buildrequires puede ser útil.
  • Requires: Una lista separada por comas de los paquetes que se requieren cuando se instala el programa. Tenga en cuenta que la etiqueta BuildRequires lista lo que se necesita para construir el RPM binario, mientras que la etiqueta Requires lista lo que se requiere para la instalación/ejecución del programa; un paquete puede estar en una lista o en ambas. En muchos casos, rpmbuild detecta automáticamente las dependencias por lo que la etiqueta Requires no siempre es necesaria. Sin embargo, puede que desee resaltar algunos paquetes específicos cuando sea necesario, o es posible que no sean detectados automáticamente.
  • %description: Una más larga, descripción multilínea del programa. Use inglés americano. Todas las líneas deben ser de 80 caracteres o menos. Las líneas en blanco indican un nuevo párrafo. Algunos programas de instalación de la interfaz gráfica de usuario reformatearán los párrafos; las líneas que comienzan con un espacio en blanco se tratan como texto preformateado y se mostrarán tal cual, normalmente con una fuente de ancho fijo. Consulte Guía RPM.
  • %prep: Comandos de script para «preparar» el programa (por ejemplo, para descomprimirlo) y que pueda estar listo para la construcción. Típicamente es sólo «%setup -q»; una variación común es «%setup -q -n NOMBRE» si el archivo fuente se desempaqueta en NOMBRE. Consulte la sección %prep de abajo para más detalles.
  • %build: Comandos de script para «construir» el programa (por ejemplo, para compilarlo) y prepararlo para la instalación. El programa debe venir con instrucciones de cómo hacerlo. Vea la sección %build de abajo para más detalles.
  • %check: Comandos de script para «probar» el programa. Estos se ejecutan entre los procedimientos %build e %install, así que debe colocarlo allí si tiene esta sección. A menudo simplemente contiene «make test» o «make check». Esto es aparte de %build para que las personas puedan omitir la comprobación automática si lo desean.
  • %install: Comandos de script para «instalar» el programa. Los comandos deben copiar los archivos desde el directorio de CONSTRUCCIÓN %{_builddir} al directorio raíz de construcción, %{buildroot}. Vea la sección %install de abajo para más detalles.
  • %clean: Instrucciones para limpiar la raíz de construcción. Tenga en cuenta que esta sección es ahora redundante en Fedora y sólo es necesaria para EPEL. Normalmente esto sólo contiene:
rm -rf %{buildroot}
  • %files: La lista de archivos que serán instalados. Consulte la sección %files de abajo para más detalles.
  • %changelog: Cambios en el paquete. Utilice de ejemplo el formato anterior.
  • ExcludeArch: Si el paquete no compila, construye o funciona correctamente en una arquitectura en particular, liste esas arquitecturas bajo esta etiqueta.
  • Puede agregar secciones para que el código se ejecute cuando los paquetes sean instalados o removidos en el sistema real (en lugar de sólo ejecutar el script %install, que sólo hace una pseudo-instalación a la raíz de construcción). Estos se denominan «scriptlets», y se utilizan generalmente para actualizar el sistema en ejecución con información del paquete. Consulte la sección «Scriptlets» de abajo para más detalles.

RPM también soporta la creación de varios paquetes (llamados subpaquetes) desde un único archivo SPEC, como los paquetes name-libs y name-devel.

No use estas etiquetas:

  • Packager
  • Vendor
  • Copyright

No cree un paquete «relocalizable»; que no agrega valor en Fedora y hace las cosas más complicadas.

Secciones del archivo SPEC explicadas

Sección %prep

La sección %prep describe cómo desempaquetar los paquetes comprimidos para que puedan ser construidos. Típicamente, esto incluye los comandos «%setup» y «%patch» con referencia a las líneas Source0 (y Source1, etc.). Vea la sección %setup y %patch en Maximum RPM para más detalles.

Las macros %{patches} y %{sources} están disponibles desde RPM 4.4.2 y son útiles si usted tiene una gran lista de parches o fuentes:

for p in %{patches}; do
    ...
done

Sin embargo, tenga en cuenta que el uso de estas hará a su SPEC incompatible con los RPMS utilizados en RHEL y otras distribuciones basadas en RPM.

Sección %prep: comando %setup

El comando «%setup» desempaqueta un paquete fuente. Los modificadores incluyen:

  • -q : Suprime la salida innecesaria. Este es comúnmente utilizado.
  • -n nombre : Si el archivo tarball Fuente se desempaqueta en un directorio cuyo nombre no es el nombre del RPM, este modificador puede utilizarse para especificar el nombre del directorio correcto. Por ejemplo, si el archivo tarball se desempaqueta en el directorio FOO, use «%setup -q -n FOO».
  • -c nombre : Si el archivo tarball Fuente se desempaqueta en varios directorios en lugar de un solo directorio, este modificador puede utilizarse para crear un directorio llamado nombre y luego descomprimir en él.

Hay más opciones %spec si está desempaquetando múltiples archivos, lo cual es especialmente útil si está creando subpaquetes (ver más abajo). Las más importantes son:

-a número Sólo desempaquetar la directiva Fuente del número dado después de cambiar de directorio (por ejemplo «–a 0» para Source0).
-b número Sólo desempaquetar la directiva Fuente del número dado antes de cambiar de directorio (por ejemplo «–b 0» para Source0).
-D No eliminar el directorio antes de desempaquetar.
-T Inhabilitar el desempaquetado automático del archivador.

Sección %prep: comando %patch

El comando «%patch0» aplica el Parche0 (y %patch1 aplica Parche1, etc.). Los parches son el método habitual de realizar los cambios necesarios en el código fuente para el empaquetamiento. La usual opción «-pNUMERO» se aplica, la que pasa ese argumento al patch en el programa.

Los nombres de los archivos parche usualmente lucen como «telnet-0.17-env.patch», que es el formato «%{name} - %{version} - RAZÓN.patch» (aunque a veces se omite la versión). Los archivos parche son típicamente el resultado de «diff -u»; si hace esto desde el subdirectorio ~/rpmbuild/BUILD entonces no tendrá que especificar un nivel -p posterior.

Este es un procedimiento típico para crear un parche para un solo archivo:

cp foo/bar foo/bar.orig
vim foo/bar
diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/NOMBREDEPAQUETE.RAZÓN.patch

Si va a editar muchos archivos, un método fácil es copiar el subdirectorio completo debajo de BUILD y luego hacer diffs por subdirectorio. Después de cambiar al directorio «~rpmbuild/BUILD/NOMBRE», haga lo siguiente:

cp -pr ./ ../NOMBREDEPAQUETE.orig/
... muchas ediciones ...
diff -u ../NOMBREDEPAQUETE.orig . > ~/rpmbuild/SOURCES/NOMBRE.RAZÓN.patch

Si edita muchos archivos en un parche, también puede copiar los archivos originales mediante alguna terminación consistente como «.orig» antes de editarlos. Luego, puede usar «gendiff» (en el paquete rpm-build) para crear un parche con las diferencias.

Trate de asegurarse que el parche coincida exactamente con el contexto. El valor por omisión de «fuzz» es «0», que requiere coincidencia para ser exacto. Puede solucionar esto añadiendo «%global _default_patch_fuzz 2» para volver al valor encontrado en las versiones anteriores de RPM en Fedora, pero en general se recomienda evitar hacer esto.

Como se explica en Packaging/PatchUpstreamStatus, todos los parches deben tener un comentario sobre ellos en el archivo SPEC sobre su estado de desarrollo. Este debe documentar el desarrollo que incluye los errores/correo electrónico (incluyendo la fecha). Si es exclusivo de Fedora, debe mencionar por qué es único. El proyecto Fedora intenta no desviarse del desarrollo; consulte PackageMaintainers/WhyUpstream para ver la importancia de esto.

Sección %prep: Archivos sin modificar

A veces, uno o más de los archivos Fuente no necesitarán ser descomprimidos. Usted puede «prep» esos archivos en un directorio de construcción como este (donde SOURCE1 se refiere al archivo Fuente correspondiente):

cp -p %SOURCE1 .

Sección %build

La sección «%build» es a veces complicada; aquí usted configura y compila/construye los archivos a ser instalados.

Muchos programas siguen el enfoque configure de GNU (o alguna variación). De forma predeterminada, se instalarán con un prefijo de «/usr/local», que es razonable para los archivos desempaquetados. Sin embargo, como usted está empaquetándolo, cambiará el prefijo a «/usr». Las librerías deben instalarse bien sea en /usr/lib o /usr/lib64 dependiendo de la arquitectura.

Ya que configure de GNU es tan común, la macro «%configure» se puede utilizar para invocar automáticamente las opciones correctas (por ejemplo, cambiar el prefijo a /usr). Alguna variación de esto a menudo funciona:

 %configure
 make %{?_smp_mflags}

Para sustituir variables en el makefile, pasarlas como parámetros a make:

make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}

Más información, consulte «GNU autoconf, automake, and libtool» y «Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf» por Stefan Hundhammer.

Algunos programas usan cmake. Ver Packaging/cmake.

Sección %check

Si las pruebas automáticas están disponibles, por lo general es una buena idea incluirlas. Deben colocarse en la sección %check (que sigue inmediatamente a la sección %build) en lugar de dentro de la sección %build, de modo que puedan ser fácilmente omitidas cuando sea necesario.

A menudo, esta sección contiene:

make test

Sección %install

Esta sección incluye comandos de script para «instalar» el programa, copiar los archivos relevantes desde %{_builddir} a %{buildroot} (que por lo general significa desde ~/rpmbuild/BUILD a ~/rpmbuild/BUILDROOT) y la creación de directorios dentro de %{buildroot} según sea necesario.

Parte de la terminología que puede inducir a error:

  • El «directorio de construcción», también conocido como %{_builddir} no es el mismo que el «raíz de construcción», también conocido como %{buildroot}. La compilación se produce en el primer directorio, mientras que los archivos a ser empaquetados son copiados desde el primero al último.
  • Durante la sección de %build, el directorio actual comenzará en %{buildsubdir}, que es el subdirectorio dentro de %{_builddir} creado durante la etapa de %prep. Esto suele ser algo como ~/rpmbuild/BUILD/%{name}-%{version}.
  • La sección %install no no se ejecuta cuando el paquete RPM binario es instalado por el usuario final, pero sólo se ejecuta cuando se crea un paquete.

Normalmente, una variación de «make install» se lleva a cabo aquí:

%install
rm -rf %{buildroot}
make DESTDIR=%{buildroot} install

La eliminación de %{buildroot} ya no es necesaria, excepto para EPEL 5.

Idealmente debe usar DESTDIR=%{buildroot} si el programa lo admite, ya que redirige las instalaciones del archivo al directorio especificado y es exactamente lo que queremos que ocurra durante la sección %install.

Si el programa no admite DESTDIR (y sólo si), es posible la solución en una de las varias formas (inferiores):

  • Parchar el makefile así es compatible con DESTDIR. Crear directorios dentro de DESTDIR cuando sea necesario y enviar el parche a desarrollo.
  • Usar la macro «%makeinstall». Este método podría funcionar, pero puede conducir a fallas sutiles. Se expande a algo así como «make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install», lo cual puede resultar que en algunos programas no funcione correctamente. Crear directorios dentro de %{buildroot} cuando sea necesario.
  • Considerar la posibilidad de usar el paquete auto-destdir. Para ello es necesario «BuildRequires: auto-destdir», y cambiar «make install» por «make-redir DESTDIR=%{buildroot} install». Esto sólo funciona bien si la instalación utiliza sólo ciertos comandos comunes para instalar los archivos, como cp e install.
  • Realizar la instalación a mano. Esto implicaría crear los directorios necesarios debajo de %{buildroot} y copiar los archivos desde %{_builddir} a %{buildroot}. Tenga especial cuidado con las actualizaciones, que a menudo contienen nombres de archivos nuevos o modificados. Un ejemplo de este procedimiento:
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_bindir}/
cp -p mycommand %{buildroot}%{_bindir}/

Como se indica en Packaging:Guidelines#Timestamps, tratar de preservar las marcas de tiempo de los archivos si el makefile permite sobrescribir comandos:

make INSTALL="install -p" CP="cp -p" DESTDIR=%{buildroot} install

Sección %files

Esta sección declara que los archivos y directorios son propiedad del paquete, por lo tanto los archivos y directorios se colocan en el RPM binario.

Conceptos básicos de %files

La %defattr establece los permisos de archivo por defecto, y se encuentra a menudo en el inicio de la sección %files. Tenga en cuenta que esto ya no es necesario a menos que los permisos deban modificarse. El formato de esta es:

%defattr(<permisos de achivo>, <usuario>, <grupo>, <permisos de directorio>)

El cuarto parámetro se omite a menudo. Usualmente se utiliza %defattr(-,root,root,-), donde «-» significa use los permisos predeterminados.

A continuación, debe listar todos los archivos y directorios a ser propiedad del paquete. Utilizar macros para los nombres de directorio donde sea posible, que pueden verse en Packaging:RPMMacros (por ejemplo, utilice %{_bindir}/mycommand en lugar de /usr/bin/mycommand). Si el patrón comienza con una «/» (o cuando se expande desde la macro) entonces se toma desde el directorio %{buildroot}. De lo contrario, se presume que el archivo está en el directorio actual (por ejemplo dentro de %{_builddir}, como los archivos de documentación que desee incluir). Si su paquete sólo instala un único archivo /usr/sbin/mycommand, la sección %files simplemente puede ser:

%files
%{_sbindir}/mycommand

Para hacer que su paquete sea menos sensible a los cambios, declare que todos los archivos dentro de un directorio sean propiedad del paquete con una coincidencia de patrón:

%{_bindir}/*

Para incluir un solo directorio:

%{_datadir}/%{name}/

Tenga en cuenta que %{_bindir}/* no reclama que este paquete sea propietario del directorio /usr/bin, pero sólo de los archivos contenidos en él. Si usted lista un directorio, entonces usted está reclamando que este paquete sea dueño de ese directorio y de todos sus archivos y subdirectorios contenidos en él. Por lo tanto, no liste el %{_bindir} y tenga cuidado con los directorios que puedan ser compartidos con otros paquetes.

Se producirá un error si:

  • una coincidencia de patrón no coincide con algún archivo o directorio
  • un archivo o directorio está listado o coincide más de una vez
  • un archivo o directorio en la %{buildroot} no ha sido listado

También es posible excluir archivos de una coincidencia anterior utilizando el glob %exclude. Esto puede ser útil para incorporar a casi todos los archivos incluidos por una coincidencia de patrón diferente, pero tenga en cuenta que también fallará si no coincide con algo.

Prefijos de %files

Puede que tenga que agregar uno o más prefijos a las líneas en la sección %files; separados con un espacio. Ver Max RPM section on %files directives.

Por lo general, «%doc» se utiliza para listar los archivos de documentación dentro de %{_builddir} que no se copiaron a %{buildroot}. Usualmente se incluyen los archivos README e INSTALL. Serán colocados en el directorio /usr/share/doc/%{name}-%{version}, cuya propiedad no necesita ser declarada.

Nota: Si se especifica una entrada %doc, entonces usted no puede copiar los archivos en el directorio de documentación durante la sección %install. Si, por ejemplo, desea un subdirectorio «ejemplos» dentro del directorio de documentación, no utilice %doc, pero en cambio cree los directorios y copie los archivos manualmente en %{buildroot}%{_defaultdocdir}/%{name}-%{version} durante la sección %install. Serán marcados correctamente como documentación. Asegúrese de incluir %{_defaultdocdir}/%{name}-%{version}/ como una entrada en la sección %files.

Los archivos de configuración deben ser colocados en /etc y normalmente son especificados como esto (lo que hace es asegurarse de que al actualizar no se sobrescriban los cambios hechos por el usuario):

%config(noreplace) %{_sysconfdir}/foo.conf

Si la actualización utiliza un formato de configuración no compatible con versiones anteriores, entonces especificarlo de la siguiente manera:

%config %{_sysconfdir}/foo.conf

«%attr(mode, user, group)» puede ser utilizado para un mayor control sobre los permisos, donde un «-» significa utilizar el valor predeterminado:

%attr(0644, root, root) FOO.BAR

Si un archivo está en un idioma natural en particular, use %lang para asentarlo:

%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*

Los programas que utilizan archivos Locale deben seguir el método recomendado para el manejo de archivos de i18n:

  • encontrar los nombres de archivo en la etapa %install: %find_lang ${name}
  • añadir las dependencias de construcción necesarias: BuildRequires: gettext
  • utilizar los nombres de archivos encontrados: %files -f ${name}.lang

Estos prefijos no son válidos en Fedora: %license y %readme.

%files y Estándar de jerarquía del sistema de archivos (FHS)

Usted debería seguir el Estándar de jerarquía del sistema de archivos (FHS). Los ejecutables van en /usr/bin, los archivos de configuración global en /etc, las librerías en /usr/lib (o /usr/lib64) y así sucesivamente. Hay una excepción: los ejecutables que no deberían ser ejecutados directamente por los usuarios o administradores deben ir en el subdirectorio /usr/libexec, lo que se conoce como %{_libexecdir}/%{name}.

No instalar los archivos en /opt o /usr/local.

Desafortunadamente, muchos programas no siguen el FHS por defecto. En particular, las librerías independientes de la arquitectura se encontrarán en /usr/lib en lugar de /usr/share. El primero es para las librerías dependientes de la arquitectura, mientras que el segundo es para las librerías independientes de la arquitectura, lo que significa que los sistemas con arquitecturas de CPU diferentes pueden compartir en /usr/share. Hay muchas excepciones en Fedora (como Python y Perl), pero Fedora aplica esta regla más estrictamente que algunas distribuciones. rpmlint generalmente se quejará si usted pone algo más que archivos ELF en /usr/lib.

Ejemplo de %files

He aquí un ejemplo simple de una sección %files:

%files
%doc README LICENSE
%{_bindir}/*
%{_sbindir}/*
%{_datadir}/%{name}/
%config(noreplace) %{_sysconfdir}/*.conf

Búsqueda de duplicados

Puede listar los duplicados de dos paquetes binarios haciendo:

cd ~/rpmbuild/RPMS/ARCH # Sustituir «ARCH» por su arquitectura
rpm -qlp PACKAGE1.*.rpm | sort > ,1
rpm -qlp PACKAGE2.*.rpm | sort > ,2
comm -12 ,1 ,2

Scriptlets

Cuando un usuario final instala el RPM, es posible que desee ejecutar algunos comandos. Esto se puede lograr a través de scriptlets. Consulte Packaging/ScriptletSnippets.

Los scriptlets se pueden ejecutar:

  • antes (%pre) o después (%post) de instalar un paquete
  • antes (%preun) o después (%postun) de desinstalar un paquete
  • al inicio (%pretrans) o al final (%posttrans) de una transacción

Por ejemplo, cada paquete RPM binario que almacena archivos de las librerías compartidas en cualquiera de las rutas de acceso predeterminadas del enlazador dinámico, debe llamar a ldconfig en %post y %postun. Si el paquete tiene varios subpaquetes con librerías, cada subpaquete también debe realizar las mismas acciones.

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

Si tan sólo ejecuta un solo comando, entonces la opción «-p» ejecuta el comando adyacente sin invocar el shell. Sin embargo, para varios comandos, omita esta opción e incluya los comandos de shell debajo.

Si ejecuta cualquier programa dentro de los scriptlets, debe especificar los requisitos en la forma «Requires(CONTEXTO)» (por ejemplo Requires(post)).

%pre, %post, %preun, y %postun ofrecen el argumento $1, que es el número de paquetes de este nombre que quedará en el sistema cuando la acción se complete. No comparar a la igualdad con 2, pero en cambio comprobar si es mayor o igual a 2. Para %pretrans y %posttrans, $1 es siempre 0.

Por ejemplo, si el paquete instala un manual de información, entonces el índice del manual de información debe ser actualizado con install-info del paquete info. En primer lugar, no hay ninguna garantía de que el paquete info estará disponible a menos que lo declaremos explícitamente como necesario, y en segundo lugar, no queremos fracasar completamente si se produce un error en install-info:

Requires(post): info
Requires(preun): info
...
%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
%preun
if [ $1 = 0 ] ; then
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

Hay otros fallos técnicos relacionados con la instalación de los manuales de información. El comando install-info actualizará el directorio de información, por lo que debemos eliminar el directorio inservible vacío de %{buildroot} durante la sección %install:

rm -f %{buildroot}%{_infodir}/dir

Otra capacidad tipo-scriptlet son los «triggers», que se pueden ejecutar con su paquete cuando otros paquetes sean instalados o desinstalados. Ver RPM Triggers.

Macros

Las macros son texto en el formato de %{string}. Macros típicas:

Macro Expansión típica Significado
%{_bindir} /usr/bin Directorio binario: donde se almacenan normalmente los ejecutables.
%{_builddir} ~/rpmbuild/BUILD Directorio de construcción: archivos que son compilados en un subdirectorio del directorio de construcción. Ver %buildsubdir.
%{buildroot} ~/rpmbuild/BUILDROOT Raíz de construcción: donde los archivos son «instalados» durante la etapa de %install, que copia los archivos desde un subdirectorio de %{_builddir} a un subdirectorio de %{buildroot}. (Históricamente, %{buildroot} estaba en «/var/tmp/».)
%{buildsubdir} %{_builddir}/%{name} Subdirectorio de construcción: un subdirectorio dentro de %{_builddir} donde se compilan los archivos durante la etapa de %build. Se establece después de %setup.
%{_datadir} /usr/share Directorio compartido.
%{_defaultdocdir} /usr/share/doc Directorio predeterminado de documentación.
%{dist} .fcNUMERO Distribución+nombre corto de versión (por ejemplo «.fc9»)
%{fedora} NUMERO Número de liberación de Fedora (por ejemplo «9»)
%{_includedir} /usr/include
%{_infodir} /usr/share/info
%{_initrddir} /etc/rc.d/init.d
%{_libdir} /usr/lib
%{_libexecdir} /usr/libexec
%{_localstatedir} /var
%{_mandir} /usr/share/man
%{name} Nombre del paquete, definido por Name: etiqueta
%{_sbindir} /usr/sbin
%{_sharedstatedir} /var/lib
%{_sysconfdir} /etc
%{version} Versión del paquete, definido por Version: etiqueta

Aprenda más sobre las macros mirando en /etc/rpm/* y /usr/lib/rpm, especialmente /usr/lib/rpm/macros. También use rpm --showrc para mostrar los valores que RPM va a utilizar en las macros (modificados por los archivos de configuración de macros y rpmrc).

Puede establecer sus propios valores de macro usando %global, pero asegúrese de definirlos antes de usarlos. (Las definiciones de macro pueden referirse a otras macros.) Por ejemplo:

%global date 2012-02-08

Use la opción «-E» de rpmbuild para encontrar el valor de una macro en un archivo SPEC:

rpmbuild -E '%{_bindir}' myfile.spec

Ver también Packaging/RPMMacros y Capítulo 9 de la guía RPM.

Otras etiquetas

Además de las etiquetas Requires y BuildRequires, también se pueden utilizar estas para controlar las dependencias:

  • Provides: lista de nombres de paquetes virtuales que este paquete ofrece. Por ejemplo, puede haber un paquete «foo» que exige una funcionalidad «bar» particular de otro programa. Si hay varios paquetes que pueden satisfacer esa demanda, esos paquetes se pueden especificar «Provides: bar» y el paquete «foo» se puede especificar «Requires: foo». También puede utilizar el sistema de «alternativas», pero evitar si varios usuarios en el mismo sistema quieren diferentes valores predeterminados, ya que estos ajustes son para todo el sistema. Use «rpm -q --provides NOMBREDEPAQUETE» para ver lo que un determinado paquete proporciona. Algunos ejemplos de paquetes virtuales en Fedora:
    • MTA: Usado para el Agente de Transferencia de Correo, tal como sendmail.
    • tex(latex): Usado para latex.
  • Obsoletes: eliminar los otros paquetes nombrados cuando estos paquetes sean instalados. Utilizar cuando cambia el nombre del paquete o cuando reemplaza totalmente a un paquete diferente.
  • Conflicts: estado de otros paquetes que no se pueden instalar al mismo tiempo con éste. Evite esto si puede. Vea Packaging/Conflicts.
  • BuildConflicts: estado de los paquetes que no se pueden instalar en la construcción de éste paquete. Evite esto si puede.

Para administrar arquitecturas diferentes, hay dos etiquetas:

  • ExcludeArch: para excluir una arquitectura en la que el paquete no se construye. Por ejemplo:
ExcludeArch: ppc
  • ExclusiveArch: para incluir sólo la arquitectura especificada. Evitar esto a menos que sea absolutamente correcto.

Las arquitecturas válidas están listadas en Arquitecturas.

Subpaquetes

Un archivo SPEC puede definir más de un paquete binario. En otras palabras, un archivo SRPM con un SPEC pueden resultar en varios RPMS. Tenga en cuenta que todavía hay sólo un proceso de creación (%prep, %build, %install, etc.). Los subpaquetes name-doc y name-devel son comunes para los archivos de documentación y desarrollo respectivamente.

Use la directiva %package para iniciar la definición de un subpaquete:

%package subpackage_name

Después de cada directiva %package, liste las etiquetas para el subpaquete. Esta debe incluir por lo menos las etiquetas Summary y Group, así como las directivas %description subpackage_name y %files subpackage_name:

Cualquier cosa no especificada por el subpaquete será heredado de su padre.

Por omisión, si el nombre del paquete es «foo» y el nombre del subpaquete es «bar», entonces el subpaquete resultante será «foo-bar». Usted puede anularlo con la opción «-n» (pero también tendrá que usarla en todas las demás directivas si la especifica aquí):

%package -n new_subpackage_name

Vea la sección subpaquetes de la Guía RPM para obtener más información.

Condicionales

Puede insertar sentencias condicionales, por ejemplo para probar, si usted está creando un binario para una arquitectura determinada:

%ifarch ARCHITECTURE_NAME

la versión negada con:

%ifnarch ARCHITECTURE_NAME

o la condicional más general:

%if TRUE_OR_FALSE

Hay una sección «%else» opcional; todos estas son cerradas con «%endif».

Lineamientos específicos de la aplicación

Existen muchos lineamientos específicos de las aplicaciones que pueden ayudarle (por ejemplo, para lenguajes de programación específicos, aplicaciones, librerías y sistemas de construcción). Muchos de ellos están listados como parte de los Lineamientos específicos de la aplicación de empaquetamiento/directrices. Ejemplos de lineamientos específicos de la aplicación son aquellos para:

En su defecto, otras maneras de encontrar ayuda específica de la aplicación son:

Varios consejos

Packaging/FrequentlyMadeMistakes tiene información sobre errores cometidos con frecuencia. También hay algunas recomendaciones y trucos controversiales en PackageMaintainers/Packaging Tricks.

Trate de escribir sus archivos SPEC para que pueda trabajar cuando se realice una nueva versión de desarrollo, sin cambios aparte de subir el número de versión y actualización de los archivos fuentes. Por ejemplo, si contiene archivos *.txt con bits de ejecución, en lugar de hacer

 chmod a-x Filename1.txt Filename2.txt Filename3.txt

considere hacer esto, lo que se encargará de los nuevos nombres de archivos que utilizan la misma convención de denominación de archivos:

 chmod a-x *.txt

Si quiere ver muchos ejemplos de scriptlets, pueden verse todos los scriptlets de los programas instalados mediante:

 rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less

No intente interactuar con el usuario; RPM está diseñado para soportar instalaciones de procesamiento por lotes. Si una aplicación necesita mostrar una EULA, debe ser parte de la ejecución inicial, no de la instalación.

Usted podría no querer iniciar los servicios, ya que en una instalación grande podría retrasar las cosas. Si instala un script init o systemd, considere usar chkconfig o systemctl para organizar que el servicio sea iniciado/detenido en el siguiente reinicio. Antes de desinstalar, debería normalmente intentar detener los servicios si se están ejecutando.

La desinstalación debe revertir la mayoría de los cambios realizados durante la instalación, pero no eliminar los archivos creados por el usuario.

Normalmente, si hay ejecutables binarios, se eliminan los símbolos de depuración de los paquetes binarios normales y se colocan en un subpaquete name-debug. Si esto no sucede, puede deshabilitar la creación y remoción de este subpaquete poniendo esto en la parte superior de su SPEC:

%global _enable_debug_package 0
%global debug_package %{nil}
%global __os_install_post /usr/lib/rpm/brp-compress %{nil}

Para evitar la remoción es posible que tenga que hacer esto en la sección %install:

export DONT_STRIP=1

Una forma de verificar la versión de Fedora en un archivo SPEC para la construcción condicional es:

%if 0%{?fedora} <= <version>

El ? provoca que la macro evalúe ponerse en blanco si %fedora no está definida. Esto hace que el resultado final sea 0 (que es un número y por lo tanto aceptable), mientras que no interfiera con el resultado si hay realmente un valor para %fedora. (Tenga en cuenta que este truco no funciona en Koji «scratch» builds, donde %fedora se establece durante la creación del SRPM.)

Los programas de la GUI deben tener una entrada desktop para que la gente pueda invocarla desde el menú gráfico de escritorio. Para los archivos .desktop, consulte Lineamientos de empaquetado de Fedora para archivos desktop y entrada desktop en spec. Para los iconos dentro de /usr/share/icons, consulte tema de ícono en spec.

Construcción del paquete binario

Prueba con rpmlint

Para detectar a tiempo muchos errores comunes, ejecute rpmlint en su archivo SPEC antes de intentar construir algo con él:

$ rpmlint program.spec

Si el error reportado no tiene sentido, ejecutarlo de nuevo con la opción «-i» para mensajes más largos.

Trate de no tener errores, pero a veces rpmlint informa falsos positivos. Los Lineamientos de empaquetamiento de Fedora explica cuáles ignorar.

Crear un RPMS binario desde el archivo SPEC

Una vez que haya creado su archivo SPEC, construir el SRPM y el RPMS binario ejecutando esto:

$ rpmbuild -ba program.spec

Si tiene éxito, RPMS se creará dentro de ~/rpmbuild/RPMS y SRPMS dentro de ~/rpmbuild/SRPMS.

Si no, vaya al directorio correspondiente y mire lo que queda. Para ayudar a depurar, puede saltarse las etapas anteriores que tuvieron éxito con la opción «--short-circuit». Por ejemplo, para reiniciar en la etapa de %install (saltando etapas anteriores), haga lo siguiente:

$ rpmbuild -bi --short-circuit program.spec

Si lo que desea es crear un SRPM (que no ejecuta la %prep o %build u otras etapas), ejecute esto:

rpmbuild -bs program.spec

Pruebas de RPMS binarios con rpmlint

rpmlint se puede ejecutar en archivos SPEC, RPMS y SRPMS para comprobar si hay errores. Es necesario para eliminar o corroborar las advertencias antes de publicar un paquete. Si usted está en el directorio SPECS, haga lo siguiente:

$ rpmlint NOMBRE.spec ../RPMS/*/NOMBRE*.rpm ../SRPMS/NOMBRE*.rpm

Introduzca el directorio ~/rpmbuild/RPMS en el subdirectorio de la arquitectura. Encontrará algunos RPMS binarios. Vea rápidamente sus archivos y permisos (para comprobar si son correctos) haciendo:

$ rpmls *.rpm

Si esto luce bien, instalarlos como root:

# rpm -ivp package1.rpm package2.rpm package3.rpm ...

Pruebe los programas de diferentes maneras para ver si todo funciona correctamente. Si se trata de una herramienta de GUI, asegúrese de que aparece en el menú del escritorio, de lo contrario la entrada .desktop será errónea.

Desinstalar los paquetes más tarde haciendo:

# rpm -e package1 package2 package3

Mock y Koji

Mock es una potente herramienta que utiliza el SRPM que usted ha creado para construir paquetes binarios dentro de un ambiente casi vacío. Esto puede revelar si tiene las dependencias de construcción adecuadas. Si esto falla, entonces se olvidó de incluir algo en BuildRequires. Consulte Usando Mock para probar las construcciones de paquetes. Una vez que su cuenta sea miembro del grupo «mock», puede ejecutar comandos como este para hacer pruebas locales:

$ mock -r fedora-9-i386 rebuild path_to_source_RPM

Puede utilizar Koji (que usa mock) para realizar construcciones en muchos sistemas diferentes, algunos de los cuales puede que no tenga. PackageMaintainers/Join y PackageMaintainers/UsingKoji tienen más información acerca de Koji. Una vez que está instalado, puede probar su SRPM en una variedad de plataformas ejecutando comandos como:

$ koji build --scratch dist-f9 path_to_source_RPM

Reemplace dist-f9 con cualquier versión posterior de Fedora, pero no use dist-rawhide. Recuerde que los valores de %fedora, %fc9 y así sucesivamente, no serán correctos para un scratch build, por lo que estos no funcionarán si el archivo SPEC hace algo diferente, basándose en esos valores.

Sus construcciones Koji sólo pueden depender de los paquetes que se encuentran actualmente en el repositorio de distribución TARGET. En consecuencia, no puede construir con Koji para distribuciones liberadas si su paquete depende de otros paquetes nuevos que Bodhi no ha liberado todavía. Si necesita construir en contra de un paquete que no es todavía una liberación estable actualizada, puede presentar un ticket con rel-eng en: https://fedorahosted.org/rel-eng/newticket y solicitar que dicho paquete sea añadido como un buildroot override.

Herramientas útiles

El paquete rpmdevtools contiene una serie de herramientas útiles; «rpm -qil rpmdevtools» le mostrará lo que instala.

  • rpmdev-bumpspec : resalta la etiqueta de la versión en el archivo spec y añade un comentario en el registro de cambios con el formato de fecha y versión correctos:
rpmdev-bumpspec --comment=COMENTARIO --userstring=NOMBRE+CORREOELECTRONICO_STRING SPECFILES

El paquete yum-utils también tiene algunas herramientas útiles:

  • yumdownloader : descargar el SRPM del paquete ejecutando:
yumdownloader --source NOMBREDEPAQUETE

El paquete auto-buildrequires tiene un par de buenas herramientas para ayudar a descifrar las entradas de BuildRequires. Después de instalar este paquete, reemplace «rpmbuild» con «auto-br-rpmbuild» y verá una lista de BuildRequires generada automáticamente.

Es posible que encuentre útil a RUST (GPL), aunque no crea archivos SPEC de la calidad adecuada para los paquetes de Fedora. Alien convierte entre formatos de paquetes. No producirá SRPMS limpios, pero la conversión de un paquete existente podría proporcionar cierta información útil.

Lineamientos y reglas

Al crear los paquetes, deberá seguir las siguientes reglas y lineamientos:

Hay muchas pautas oficiales que le ayudarán con circunstancias específicas (por ejemplo, programas Java, OCaml, GNOME, etc.). Puede aprender más desde las secciones SIGs y Maintenedores de paquetes. También puede ver la lista de todas las páginas Wiki sobre el empaquetamiento para ver si alguna es aplicable.

En su defecto, puede que encuentre algunas recomendaciones útiles en los Borradores de empaquetamiento no oficiales y en Borradores de empaquetamiento para hacer.

Mantenimiento del paquete

Una vez que su paquete ha sido aceptado, usted y sus co-mantenedores tendrán que mantenerlo. Ver CÓMO actualizar paquetes y Lineamientos de actualización de paquetes. Si actualiza la versión en varias liberaciones de Fedora, hágalo hacia atrás en el tiempo (por ejemplo, libere para Fedora N, luego una vez aceptado, Fedora N-1). El sistema presume que las versiones más recientes de Fedora poseen la misma o más recientes versiones de los programas.

Alentar a los desarrolladores principales a utilizar las convenciones estándar en la liberación del código fuente. Usando las convenciones estándar hace que el empaquetamiento sea mucho más fácil. Para obtener más información, consulte:

Para obtener más información

La página Mantenedores de paquetes enlaza a muchas otras páginas de interés, y CÓMO actualizar paquetes describe cómo actualizar un paquete existente que usted ya mantenga en Fedora.

Para obtener más información, fuera de la Wiki de Fedora, consulte:

Nota: El sitio rpm5.org tiene alguna documentación, pero no depende de él; que es la página de un fork de RPM mantenido por Jeff Johnson. El RPM utilizado por Fedora (y Novell/SuSE) se basa más bien en rpm.org. lwn.net tiene un breve artículo acerca de esto.