Paquetes RPM

[edit (https://fedoraproject.org/w/index.php?title=Template:Lang/How_to_create_an_RPM_package&action=edit) ]

How to create an RPM package/es< How to create an RPM package

In other languages: Deutsch (de) (https://fedoraproject.org/wiki/How_to_create_an_RPM_package/de)

English (en) (https://fedoraproject.org/wiki/How_to_create_an_RPM_package) Español (es)

Italiano (it) (https://fedoraproject.org/wiki/How_to_create_an_RPM_package/it)

Português (pt) (https://fedoraproject.org/wiki/How_to_create_an_RPM_package/pt)

Русский (ru) (https://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package/ru&&action=edit)

中文(中国大陆) (zh-cn) (https://fedoraproject.org/wiki/How_to_create_an_RPM_package/zh-cn)

中文(台灣) (zh-tw) (https://fedoraproject.org/wiki/How_to_create_an_RPM_package/zh-tw)

IntroducciónEsta página describe detalladamente cómo crear un paquete RPM y en particular, cómo crear un archivoSPEC. A diferencia de otras guías RPM, esta página explica los detalles de Fedora con enlaces a loslineamientos específicos de Fedora. Dado que es mantenida a través de la Wiki de Fedora, es probableque esté más al día que otras guías. A pesar del enfoque en Fedora, la mayor parte de este documento seaplica a otras distribuciones basadas en RPM. Si está impaciente, puede comenzar por mirar el más breveCó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 losLineamientos de empaquetado y Lineamientos de nombrado de paquetes. Dicho esto, esta página debeser compatible con ellos.

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

Preparando su sistemaAntes de crear paquetes RPM en Fedora, necesita instalar algunas herramientas básicas de desarrollo yconfigurar 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 deconstrucción sale mal no podrá destruir sus archivos o enviar sus claves privadas al mundo.

Usted nunca debe crear los paquetes como usuario root.

Crear un nuevo usuario con el nombre makerpm, agregar el usuario al grupo 'mock', establecer unacontraseñ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 directoriosnecesaria en su directorio home ejecutando:

$ rpmdev-setuptree

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

Los lineamientos de empaquetado recomiendan preservar los datos del archivo; usted puede hacer estoautomáticamente si usa wget o curl para obtener los archivos fuentes. Si utiliza wget para obtener losarchivos 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.

How to create an RPM package/es - FedoraProject http://fedoraproject.org/w/index.php?title=How_to_create_a...

1 de 22 30/01/13 23:09

Los fundamentos de la construcción de paquetes RPMPara crear un paquete RPM, necesitará crear un archivo de texto «.spec» que suministre la informaciónacerca del software que será empaquetado. Luego podrá ejecutar el comando rpmbuild sobre dicho archivoSPEC, 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 porlos desarrolladores originales, en el directorio ~/rpmbuild/SOURCES. deberá colocar su archivo .spec en eldirectorio ~/rpmbuild/SPECS y asignarle el nombre «NOMBRE.spec», donde NOMBRE es el nombre base delpaquete. Para crear ambos paquetes, tanto el binario como el fuente, cambie al directorio ~/rpmbuild/SPECSy ejecute:

$ rpmbuild -ba NOMBRE.spec

Cuando rpmbuild es invocado de esta manera, leerá el archivo .spec y recorrerá en orden las etapas listadasa 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

macroNombre Usualmente Propósito

%_specdirDirectorio de

especificación~/rpmbuild/SPECS Archivos de especificaciones RPM (.spec).


2 de 22 30/01/13 23:09

%_sourcedir Directorio fuente~/rpmbuild

/SOURCES

Paquete fuente prístina (por ejemplo, tarballs) y

parches.

%_builddirDirectorio de

construcción~/rpmbuild/BUILD

Los archivos fuentes son desempaquetados y

compilados en un subdirectorio dentro de este.

%_buildrootdirDirectorio raíz de

construcción~/rpmbuild

/BUILDROOT

Los archivos son instalados bajo este directorio

durante la etapa %install.

%_rpmdirDirectorio RPM

binario~/rpmbuild/RPMS

Los RPM binarios son creados y almacenados bajo

este directorio.

%_srcrpmdirDirectorio 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íficoSi 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 comenzarcon un código precompilado. Instale el archivo con la fuente original (usualmente un archivo .tar.gz) en eldirectorio ~/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. Conunas pocas excepciones, todos los binarios y bibliotecas incluidos en los paquetes de Fedora debenconstruirse 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 bibliotecas externas«incluido» en ellos. No junte bibliotecas externas con la aplicación principal en un solo paquete. Encambio, divídalos en paquetes separados.

Concesión de licencias

Sólo empaquete software que sea legal en su paquete. Ver Packaging:Guidelines#Legal, Licensing:Main yPackaging:LicensingGuidelines. En general, sólo empaquete software que sea lanzado como software decó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 bibliotecas 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 hasido empaquetado. Encontrará una lista de los paquetes existentes en la Colección de paquetes deFedora en la Base de datos de paquetes de Fedora (https://admin.fedoraproject.org/pkgdb/) . Compruebetambién las Solicitudes de revisión en progreso y la lista de Paquetes retirados. Puede utilizar losRepositorios de paquetes Git de Fedora (http://pkgs.fedoraproject.org/cgit) directamente para ver losarchivos 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 deFedora (http://mirrors.fedoraproject.org/publiclist) dentro del directorio releases/18/Everything/source/SRPMS.Reemplace «18» con la versión de Fedora que desee y descargue el paquete .src.rpm que necesita.


3 de 22 30/01/13 23:09

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 paraFedora. RPM Find (http://rpmfind.net/) 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, puedelocalizar los archivos de paquetes fuentes (no los binarios .deb) en Ubuntu (http://packages.ubuntu.com/)o Debian (http://www.debian.org/distrib/packages) (los archivos de paquetes fuentes son tarballs estándarcon un subdirectorio «debian/»). Si la colección de ports FreeBSD (http://www.freebsd.org/ports/installing.html) lo tiene, podría descargarlo del FreeBSD ports tarball (ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz) y ver si la información de empaquetado existente le ayuda como punto departida. Sin embargo, esto a veces no es útil para todos. Las diferentes distribuciones tienen diferentesreglas y lo que hacen en algunos casos puede ser inapropiado para Fedora.

Creando un archivo SPECAhora necesita crear un archivo SPEC en el directorio ~/rpmbuild/SPECS. Debería nombrarlo de acuerdo alnombre del programa (por ejemplo «program.spec»). Use donde se pueda el nombre de archivo o el nombrepublicado 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 necesariamentecumple 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%configuremake %{?_smp_mflags}

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

%cleanrm -rf %{buildroot}

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


4 de 22 30/01/13 23:09

%changelog

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

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 depaquetes. Adivinará también qué tipo de plantilla utilizar basándose en el nombre del paquete, o puedeespecificarle 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 paraun módulo python:

cd ~/rpmbuild/SPECSrpmdev-newspec python-antigravityvi 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 controlName: ejectVersion: 2.1.5Release: 21%{?dist}License: GPLv2+Group: System Environment/BaseSource: %{name}-%{version}.tar.gzPatch1: eject-2.1.1-verbose.patchPatch2: eject-timeout.patchPatch3: eject-2.1.5-opendevice.patchPatch4: eject-2.1.5-spaces.patchPatch5: eject-2.1.5-lock.patchPatch6: eject-2.1.5-umount.patchURL: http://www.pobox.com/~tranterExcludeArch: s390 s390xBuildRequires: gettextBuildRequires: libtool

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

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

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

%build%configuremake %{?_smp_mflags}

%installmake 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/*


5 de 22 30/01/13 23:09

%changelog* Tue Feb 08 2011 Fedora Release Engineering <[email protected]> - 2.1.5-21- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild

* Fri Jul 02 2010 Kamil Dudka <[email protected]> 2.1.5-20- handle multi-partition devices with spaces in mount points properly (#608502)

Resumen del archivo SPECOtras guías útiles:

Guía RPM (http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide

/ch-creating-rpms.html) describe cómo escribir un archivo SPEC.

Las series de IBM «Empaquetado de software con RPM» Parte 1 (http://www.ibm.com/developerworks

/ssa/linux/library/l-rpm1/) , Parte 2 (http://www.ibm.com/developerworks/ssa/linux/library/l-rpm2/) , y

Parte 3 (http://www.ibm.com/developerworks/ssa/linux/library/l-rpm3/) .

Maximum RPM (http://rpm.org/max-rpm-snapshot/) tiene la información más completa, pero es

anticuado.

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

Insertar los comentarios con el primer carácter «#», pero evite las macros (comienzan con %) que seanpotencialmente multilíneas (las que se expanden primero). Si está comentando una línea, doble los signosde 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 Releaserespectivamente. Cuando cambia la etiqueta, las macros se actualizan automáticamente para utilizar elnuevo 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

(http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide

/chap-Packagers_Guide-Spec_File_Reference-Preamble.html)

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.


6 de 22 30/01/13 23:09

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 auto-buildrequires

(https://admin.fedoraproject.org/pkgdb/acls/name/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, 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 (http://docs.fedoraproject.org/drafts

/rpm-guide-en/ch09s03.html) .

%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


7 de 22 30/01/13 23:09

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 archivoSPEC, 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 serconstruidos. Típicamente, esto incluye los comandos «%setup» y «%patch» con referencia a las líneasSource0 (y Source1, etc.). Vea la sección %setup y %patch en Maximum RPM (http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html) para más detalles.

Las macros %{patches} y %{sources} están disponibles desde RPM 4.4.2 y son útiles si usted tiene unagran 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 enRHEL 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


8 de 22 30/01/13 23:09

descomprimir en él.

Hay más opciones %spec si está desempaquetando múltiples archivos (http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html) , 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étodohabitual 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 sontípicamente el resultado de «diff -u»; si hace esto desde el subdirectorio ~/rpmbuild/BUILD entonces notendrá 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.origvim foo/bardiff -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 yluego hacer diffs por subdirectorio. Después de cambiar al directorio «~rpmbuild/BUILD/NOMBRE», haga losiguiente:

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 algunaterminación consistente como «.orig» antes de editarlos. Luego, puede usar «gendiff» (en el paqueterpm-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, peroen general se recomienda evitar hacer esto.

Como se explica en Packaging/PatchUpstreamStatus, todos los parches deben tener un comentario sobreellos en el archivo SPEC sobre su estado de desarrollo. Este debe documentar el desarrollo que incluye loserrores/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/WhyUpstreampara 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» esosarchivos en un directorio de construcción como este (donde SOURCE1 se refiere al archivo Fuentecorrespondiente):

cp -p %SOURCE1 .

Sección %build

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


9 de 22 30/01/13 23:09

Muchos programas siguen el enfoque configure de GNU (o alguna variación). De forma predeterminada, seinstalarán con un prefijo de «/usr/local», que es razonable para los archivos desempaquetados. Sinembargo, como usted está empaquetándolo, cambiará el prefijo a «/usr». Las bibliotecas deben instalarsebien 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 invocarautomáticamente las opciones correctas (por ejemplo, cambiar el prefijo a /usr). Alguna variación de estoa 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» (http://sourceware.org/autobook/) y«Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf» por StefanHundhammer (http://www.suse.de/~sh/automake/automake.pdf) .

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. Debencolocarse en la sección %check (que sigue inmediatamente a la sección %build) en lugar de dentro de lasecció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 lacreació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í:

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

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

Idealmente debe usar DESTDIR=%{buildroot} (http://www.gnu.org/prep/standards/html_node/DESTDIR.html) siel programa lo admite, ya que redirige las instalaciones del archivo al directorio especificado y esexactamente 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.


10 de 22 30/01/13 23:09

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:

%installrm -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 losarchivos 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 ydirectorios 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 lasecció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 «-» significause los permisos predeterminados.

A continuación, debe listar todos los archivos y directorios a ser propiedad del paquete. Utilizar macrospara los nombres de directorio donde sea posible, que pueden verse en Packaging:RPMMacros (porejemplo, utilice %{_bindir}/mycommand en lugar de /usr/bin/mycommand). Si el patrón comienza con una «/» (ocuando se expande desde la macro) entonces se toma desde el directorio %{buildroot}. De lo contrario, sepresume que el archivo está en el directorio actual (por ejemplo dentro de %{_builddir}, como los archivosde documentación que desee incluir). Si su paquete sólo instala un único archivo /usr/sbin/mycommand, lasecció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 undirectorio 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, perosólo de los archivos contenidos en él. Si usted lista un directorio, entonces usted está reclamando queeste paquete sea dueño de ese directorio y de todos sus archivos y subdirectorios contenidos en él. Por lotanto, no liste el %{_bindir} y tenga cuidado con los directorios que puedan ser compartidos con otrospaquetes.


11 de 22 30/01/13 23:09

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, perotenga 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 unespacio. Ver Max RPM section on %files directives (http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html) .

Por lo general, «%doc» se utiliza para listar los archivos de documentación dentro de %{_builddir} que no secopiaron a %{buildroot}. Usualmente se incluyen los archivos README e INSTALL. Serán colocados en eldirectorio /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 dedocumentación durante la sección %install. Si, por ejemplo, desea un subdirectorio «ejemplos» dentro deldirectorio de documentación, no utilice %doc, pero en cambio cree los directorios y copie los archivosmanualmente en %{buildroot}%{_defaultdocdir}/%{name}-%{version} durante la sección %install. Serán marcadoscorrectamente como documentación. Asegúrese de incluir %{_defaultdocdir}/%{name}-%{version}/ como unaentrada en la sección %files.

Los archivos de configuración deben ser colocados en /etc y normalmente son especificados como esto (loque 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, entoncesespecificarlo 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 dearchivos 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) (http://www.pathname.com/fhs/) . Los ejecutables van en /usr/bin, los archivos de configuración global en /etc, las bibliotecas en/usr/lib (o /usr/lib64) y así sucesivamente. Hay una excepción: los ejecutables que no deberían serejecutados directamente por los usuarios o administradores deben ir en el subdirectorio /usr/libexec, loque 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 bibliotecasindependientes de la arquitectura se encontrarán en /usr/lib en lugar de /usr/share. El primero es para las


12 de 22 30/01/13 23:09

bibliotecas dependientes de la arquitectura, mientras que el segundo es para las bibliotecasindependientes de la arquitectura, lo que significa que los sistemas con arquitecturas de CPU diferentespueden compartir en /usr/share. Hay muchas excepciones en Fedora (como Python y Perl), pero Fedoraaplica esta regla más estrictamente que algunas distribuciones. rpmlint generalmente se quejará si ustedpone 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 arquitecturarpm -qlp PACKAGE1.*.rpm | sort > ,1rpm -qlp PACKAGE2.*.rpm | sort > ,2comm -12 ,1 ,2

Scriptlets

Cuando un usuario final instala el RPM, es posible que desee ejecutar algunos comandos. Esto se puedelograr 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 bibliotecas compartidas encualquiera de las rutas de acceso predeterminadas del enlazador dinámico, debe llamar a ldconfig en %posty %postun. Si el paquete tiene varios subpaquetes con bibliotecas, cada subpaquete también debe realizarlas 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 elshell. 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 quequedará en el sistema cuando la acción se complete. No comparar a la igualdad con 2, pero en cambiocomprobar 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 deinformación debe ser actualizado con install-info del paquete info. En primer lugar, no hay ningunagarantía de que el paquete info estará disponible a menos que lo declaremos explícitamente comonecesario, y en segundo lugar, no queremos fracasar completamente si se produce un error eninstall-info:

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


13 de 22 30/01/13 23:09

fi

Hay otros fallos técnicos relacionados con la instalación de los manuales de información. El comandoinstall-info actualizará el directorio de información, por lo que debemos eliminar el directorio inserviblevací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 otrospaquetes sean instalados o desinstalados. Ver RPM Triggers (http://rpm.org/api/4.4.2.2/triggers.html) .

Macros

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

MacroExpansión

típicaSignificado

%{_bindir} /usr/bin Directorio binario: donde se almacenan normalmente los ejecutables.

%{_builddir} ~/rpmbuild/BUILDDirectorio 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 losarchivos de configuración de macros y rpmrc).

Puede establecer sus propios valores de macro usando %global, pero asegúrese de definirlos antes de


14 de 22 30/01/13 23:09

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 (http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s07.html) .

Otras etiquetas

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

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»

(http://dailypackage.fedorabook.com/index.php?/archives/6-Wednesday-Why-The-Alternatives-

System.html) , 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 unSPEC 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 dedocumentació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 menoslas 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.


15 de 22 30/01/13 23:09

Por omisión, si el nombre del paquete es «foo» y el nombre del subpaquete es «bar», entonces elsubpaquete resultante será «foo-bar». Usted puede anularlo con la opción «-n» (pero también tendrá queusarla 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 (http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s04.html) para obtener más información.

Condicionales

Puede insertar sentencias condicionales, por ejemplo para probar, si usted está creando un binario parauna 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, paralenguajes de programación específicos, aplicaciones, bibliotecas y sistemas de construcción). Muchos deellos están listados como parte de los Lineamientos específicos de la aplicación deempaquetamiento/directrices. Ejemplos de lineamientos específicos de la aplicación son aquellos para:

Cmake

Emacs

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

El comando 'SEARCH' en Fedoraproject.org

PackagingDrafts

Un Grupo de interés especial (SIG)

Páginas wiki con el prefijo 'Packaging' (http://fedoraproject.org/wiki/Special:PrefixIndex/Packaging)

Varios consejos

Packaging/FrequentlyMadeMistakes tiene información sobre errores cometidos con frecuencia. Tambiénhay 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 dedesarrollo, sin cambios aparte de subir el número de versión y actualización de los archivos fuentes. Porejemplo, 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 mismaconvenció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 instaladosmediante:


16 de 22 30/01/13 23:09

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

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

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

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

Normalmente, si hay ejecutables binarios, se eliminan los símbolos de depuración de los paquetesbinarios normales y se colocan en un subpaquete name-debug. Si esto no sucede, puede deshabilitar lacreació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 resultadofinal sea 0 (que es un número y por lo tanto aceptable), mientras que no interfiera con el resultado si hayrealmente 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 elmenú gráfico de escritorio. Para los archivos .desktop, consulte Lineamientos de empaquetado de Fedorapara archivos desktop y entrada desktop en spec (http://standards.freedesktop.org/desktop-entry-spec/latest/) . Para los iconos dentro de /usr/share/icons, consulte tema de ícono en spec(http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html) .

Construcción del paquete binario

Prueba con rpmlint

Para detectar a tiempo muchos errores comunes, ejecute rpmlint en su archivo SPEC antes de intentarconstruir 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 deempaquetamiento 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


17 de 22 30/01/13 23:09

etapas anteriores que tuvieron éxito con la opción «--short-circuit». Por ejemplo, para reiniciar en la etapade %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 necesariopara eliminar o corroborar las advertencias antes de publicar un paquete. Si usted está en el directorioSPECS, 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 RPMSbinarios. 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 unaherramienta 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 KojiMock es una potente herramienta que utiliza el SRPM que usted ha creado para construir paquetesbinarios dentro de un ambiente casi vacío. Esto puede revelar si tiene las dependencias de construcciónadecuadas. Si esto falla, entonces se olvidó de incluir algo en BuildRequires. Consulte Usando Mock paraprobar las construcciones de paquetes. Una vez que su cuenta sea miembro del grupo «mock», puedeejecutar 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 delos cuales puede que no tenga. PackageMaintainers/Join y PackageMaintainers/UsingKoji tienen másinformación acerca de Koji. Una vez que está instalado, puede probar su SRPM en una variedad deplataformas 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 losvalores de %fedora, %fc9 y así sucesivamente, no serán correctos para un scratch build, por lo que estos nofuncionará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 elrepositorio de distribución TARGET. En consecuencia, no puede construir con Koji para distribucionesliberadas si su paquete depende de otros paquetes nuevos que Bodhi no ha liberado todavía. Si necesitaconstruir en contra de un paquete que no es todavía una liberación estable actualizada, puede presentarun ticket con rel-eng en: https://fedorahosted.org/rel-eng/newticket y solicitar que dicho paquete seaañadido como un buildroot override.


18 de 22 30/01/13 23:09

Herramientas útilesEl paquete rpmdevtools contiene una serie de herramientas útiles; «rpm -qil rpmdevtools» le mostrará lo queinstala.

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 deBuildRequires. Después de instalar este paquete, reemplace «rpmbuild» con «auto-br-rpmbuild» y verá unalista de BuildRequires generada automáticamente.

Es posible que encuentre útil a RUST (http://rust.sourceforge.net/) (GPL), aunque no crea archivos SPECde la calidad adecuada para los paquetes de Fedora. Alien (http://kitenet.net/~joey/code/alien/) convierteentre formatos de paquetes. No producirá SRPMS limpios, pero la conversión de un paquete existentepodría proporcionar cierta información útil.

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

Cómo unirse a los Mantenedores de la colección de paquetes de Fedora

Lineamientos de empaquetamiento

Lineamientos de nombrado de paquetes

Lineamientos de licenciamiento de paquetes

Lineamientos de la etiqueta Dist

Lineamientos de revisión de paquetes

Hay muchas pautas oficiales que le ayudarán con circunstancias específicas (por ejemplo, programasJava, 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 (https://fedoraproject.org/wiki/Special:Prefixindex/Packaging) para ver si alguna es aplicable.

En su defecto, puede que encuentre algunas recomendaciones útiles en los Borradores deempaquetamiento (https://fedoraproject.org/wiki/Special:Search?ns0=1&search=PackagingDrafts%2F&searchx=Search) no oficiales y en Borradores de empaquetamiento para hacer.

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

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

Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation (http://www.dwheeler.com

/essays/releasing-floss-software.html) (un resumen rápido)

GNU Coding Standards release process (http://www.gnu.org/prep/standards/html_node/Managing-

Releases.html)

Software Release Practice HOWTO (http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/)


19 de 22 30/01/13 23:09

Filesystem Hierarchy Standard (FHS) (http://www.pathname.com/fhs/)

Packaging Unix software (http://offog.org/articles/packaging/)

Para obtener más informaciónLa página Mantenedores de paquetes enlaza a muchas otras páginas de interés, y CÓMO actualizarpaquetes 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:

How to build RPM packages on Fedora (http://www.g-loaded.eu/2006/04/05/how-to-build-rpm-packages-

on-fedora/) - muy breve repaso

Empaquetado de software con RPM (developerWorks) Part 1 (http://www.ibm.com/developerworks

/ssa/linux/library/l-rpm1/) , Part 2 (http://www.ibm.com/developerworks/ssa/linux/library/l-rpm2/) , y Part

3 (http://www.ibm.com/developerworks/ssa/linux/library/l-rpm3/)

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

Fedora Packager's Handbook (http://koti.welho.com/vskytta/packagers-handbook/packagers-

handbook.html)

When Sally met Eddie (http://www.redhatmagazine.com/2008/02/28/when-sally-met-eddie-the-fedora-

package-story/) - un cuento simple, pero pocos detalles

Maximum RPM Book (http://rpm.org/max-rpm-snapshot/) - información más completa, pero en algunos

casos antigua/obsoleta

RPM Guide, section on creating RPMs (http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation

/0.1/html/RPM_Guide/ch-creating-rpms.html) - esta tiene un montón de buena información y es un poco

más actualizada, pero es un proyecto

Developer's guide, section on building RPMs (http://docs.fedoraproject.org/developers-guide/ch-

rpm-building.html)

Creating RPMS slides (http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF)

de Guru Labs

The fight, my first attempt to make a readable rpm package building introduction. (http://freshrpms.net

/docs/fight/)

Cambridge RPM tutorial (http://www-uxsup.csx.cam.ac.uk/talks/rpmbuild/rpmbuild.pdf) es una

presentación sobre la creación de RPM básicos

RPM HOWTO: RPM at Idle by Donnie Barnes (http://en.tldp.org/HOWTO/RPM-HOWTO/index.html)

RPM HowTo by Dawson (http://home.fnal.gov/~dawson/rpms/howto/index.html)

Cross-distribution package HOWTO (http://en.opensuse.org/Build_Service

/cross_distribution_package_how_to) tiene consejos si usted está construyendo un RPM para muchas

distribuciones.

Mandriva Rpm HowTo (en) (http://wiki.mandriva.com/en/Development/Howto/RPM) 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.

Creating Your Own Linux RPM's - The Initial Software Build (http://linuxshellaccount.blogspot.com

/2008/03/creating-your-own-linux-rpms-initial.html) 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».

All you need to know about RPM (http://fedoranews.org/alex/tutorial/rpm/) (más sobre la instalación de

paquetes que de crearlos)

La Wiki de rpm.org (http://wiki.rpm.org/) tiene algunas informaciones útiles, tal como la lista de

problemas RPM conocidos (http://wiki.rpm.org/Problems)

Nota: El sitio rpm5.org (http://rpm5.org/) tiene alguna documentación, pero no depende de él; que es la


20 de 22 30/01/13 23:09

página de un fork de RPM mantenido por Jeff Johnson. El RPM utilizado por Fedora (y Novell/SuSE) se basamás bien en rpm.org (http://www.rpm.org) . lwn.net tiene un breve artículo (http://lwn.net/Articles/236029/) acerca de esto.

Retrieved from "https://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package

/es&oldid=315883"

Categories: How to Package Maintainers Spanish translations


21 de 22 30/01/13 23:09

Copyright © 2013 Red Hat, Inc. and others. All Rights Reserved. For comments or queries, please contact us.The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat

is not responsible for content.This page was last modified on 25 December 2012, at 23:37. Content is available under Attribution-Share Alike 3.0 Unported.

Sponsors Legal Trademark Guidelines


22 de 22 30/01/13 23:09

Documents

Paquetes RPM