RPM COMO

RPM COMO
Donnie Barnes, [email protected]
Traductor: Antonio Ismael Olea Gonz�lez,
[email protected] 2:345/[email protected]
V2.0, April 8, 1997

Este documento describe el uso del formato de paquetes de instalaci�n
que se ha convertido en est�ndar de facto, el RPM (RedHat Package Man�
ager)
______________________________________________________________________

�ndice General:

1. Introducci�n

2. Visi�n general

3. Informaci�n general

3.1. Adquirir RPM

3.2. Requerimientos de RPM

4. Usando RPM

5. Y ahora, �qu� puedo hacer de verdad con RPM?

6. Construyendo paquetes RPM

6.1. El fichero rpmrc

6.2. El fichero spec

6.3. La Cabecera

6.4. %prep

6.5. %build

6.6. %install

6.7. Guiones opcionales pre y post Install/Uninstall

6.8. %files

6.9. Construcci�n

6.9.1. ``El �rbol de Directorios de los Fuentes''

6.9.2. Prueba de construcci�n

6.9.3. Creaci�n de la Lista de Ficheros

6.9.4. Construyendo el paquete con RPM

6.10. Prob�ndolo

6.11. �Qu� hacer con los nuevos paquetes RPM?

6.12. �Y ahora qu�?

7. Construcci�n multi-arquitectura de paquetes RPM

7.1. Ejemplo de fichero spec

7.2. Optflags

7.3. Macros

7.4. Excluyendo arquitectura de los paquetes.

7.5. Acabando

8. Copyright

9. Anexo: El INSFLUG
______________________________________________________________________

1. Introducci�n

RPM es el gestor de paquetes de Red Hat (Red Hat Package Manager).
Aunque aparece Red Hat en su nombre, la intenci�n es que sea un
sistema de empaquetado abierto y disponible para el uso de cualquiera.
Permite a los usuarios tomar el c�digo fuente (source code) y
empaquetarlo en forma de fuentes y binaria de forma que los ficheros
binarios sean f�cilmente instalables y rastreables y los fuentes
puedan ser reconstruidas con facilidad. Tambi�n gestiona una base de
datos de todos los paquetes y sus ficheros que puede ser usada para
verificar paquetes e interrogarla para obtener informaci�n acerca de
ficheros y/o paquetes.

Red Hat Software anima a otros vendedores de distribuciones a dedicar
un rato para examinar RPM y usarlo para sus propias distribuciones.
RPM es completamente flexible y f�cil de usar, aunque provee la base
para un sistema muy extenso. Tambi�n es completamente abierto y
disponible aunque agradecer�amos informes de fallos (bugs) y sus
reparaciones (fixes). Se concede permiso para usar y distribuir RPM,
libre de royalties, bajo la protecci�n de la licencia GPL.

Puede encontrar informaci�n m�s completa sobre RPM en el libro de Ed
Bailey Maximum RPM. Dicho libro est� disponible en www.redhat.com.

2. Visi�n general

Primero, perm�tame expresar parte de la filosof�a tras RPM. Uno de los
objetivos del dise�o fue permitir el uso de fuentes ``pr�stinas (--
N.T.: originales--)

Con RPP (nuestro anterior sistema de empaquetado del cual RPM no
deriva en absoluto), nuestros paquetes de fuentes deb�an ser
``hackeados (-- N.T.: retocados--) �aplicaciones desde ellos.
Te�ricamente, se pod�a instalar un paquete fuente RPP y efectuarle un
make sin problemas. Pero los fuentes no eran las originales, y no
hab�a referencia alguna a los cambios que hab�amos hecho para que
pudieran compilar. Se hac�a pues necesario bajarse los fuentes
originales de forma separada.

Con RPM, tiene los fuentes originales junto al ``parche (-- N.T.:
patch en el original--) �compilarlo. Vemos en esto una gran ventaja.
�Por qu�? Son varias las razones. La primera es que si sale disponible
una nueva versi�n de un programa, usted no necesita empezar desde la
nada para conseguir que compile bajo RHL. Puede examinar el parche
para saber qu� podr�a necesitar hacer. De esta manera toda la
configuraci�n por defecto de compilaci�n queda f�cilmente a la vista.

RPM tambi�n est� dise�ado para disponer de potentes par�metros de
consulta. Usted puede hacer b�squedas de paquetes a lo largo de toda
la base de datos o s�lo de ciertos ficheros. Tambi�n puede encontrar
f�cilmente a qu� paquete pertenece un fichero y de d�nde proviene. Los
ficheros RPM en s� mismos son archivos comprimidos, pero puede
consultar paquetes independientes f�cil y r�pidamente, gracias a una
cabecera binaria a medida a�adida al paquete con toda la informaci�n
que puede necesitar, almacenada sin comprimir. Esto permite consultas
r�pidas.

Otra poderosa caracter�stica es la habilidad de verificar paquetes. Si
est� preocupado por haber borrado alg�n fichero importante, s�lo tiene
que verificar el paquete. Quedar� cumplidamente informado de cualquier
anomal�a. Llegados a ese punto, podr� reinstalar el paquete si lo
considera necesario. Cualquier fichero de configuraci�n que usted
tenga quedar� a salvo.

Queremos agradecer a los colegas de la distribuci�n BOGUS por muchas
de sus ideas y conceptos que han sido incluidos en RPM. Aunque RPM
est� completamente escrito por Red Hat Software, su funcionamiento
est� basado en c�digo escrito por BOGUS (PM y PMS).

3. Informaci�n general

3.1. Adquirir RPM

La mejor forma de conseguir RPM es instalando Red Hat Commercial
Linux. Si no quiere hacer eso, puede seguir usando RPM. Puede
conseguirse en:

ftp.redhat.com/pub/redhat/code/rpm

3.2. Requerimientos de RPM

El principal requerimiento para ejecutar RPM es cpio 2.4.2 o superior.
Aunque el sistema fue ideado para ser usado con Linux, puede ser
perfectamente portado a cualquier sistema Unix. De hecho, ha sido
compilado en SunOS, Solaris, AIX, Irix, AmigaOS, y otros. Queda
advertido que los paquetes binarios generados en diferentes tipos de
sistemas Unix no ser�n compatibles.

Estos son los m�nimos requerimientos para instalar RPMs. Para
construir RPMs a partir de los fuentes, necesitar� todo lo normalmente
requerido para construir un paquete, cosas como gcc, make, etc.

4. Usando RPM

En su forma m�s simple, RPM puede usarse para instalar paquetes:

rpm -i foobar-1.0-1.i386.rpm

El siguiente comando m�s simple es desinstalar un paquete:

rpm -e foobar

Uno de los m�s complejos pero m�s �tiles comandos le permiten instalar
paquetes a trav�s de FTP. Si est� conectado a la Red y quiere instalar
un nuevo paquete, todo lo que necesita hacer es especificar el fichero
con un URL v�lido, como esto:

rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm

Aperc�base de que ahora RPM puede hacer consultas y/o instalaciones a
trav�s de FTP.

Aunque estos son comandos simples, rpm puede usarse de multitud de
formas, como puede verse en el mensaje de Ayuda:

RPM version 2.3.9
Copyright (C) 1997 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public License

usage: rpm {--help}
rpm {--version}
rpm {--initdb} [--dbpath <dir>]
rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
[--replacepkgs] [--replacefiles] [--root <dir>]
[--excludedocs] [--includedocs] [--noscripts]
[--rcfile <file>] [--ignorearch] [--dbpath <dir>]
[--prefix <dir>] [--ignoreos] [--nodeps]
[--ftpproxy <host>] [--ftpport <port>]
file1.rpm ... fileN.rpm
rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
[--oldpackage] [--root <dir>] [--noscripts]
[--excludedocs] [--includedocs] [--rcfile <file>]
[--ignorearch] [--dbpath <dir>] [--prefix <dir>]
[--ftpproxy <host>] [--ftpport <port>]
[--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
[--scripts] [--root <dir>] [--rcfile <file>]
[--whatprovides] [--whatrequires] [--requires]
[--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
[--provides] [--dump] [--dbpath <dir>] [targets]
rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
[--nomd5] [targets]
rpm {--setperms} [-afpg] [target]
rpm {--setugids} [-afpg] [target]
rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--allmatches]
package1 ... packageN
rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile <file>]
[--sign] [--test] [--timecheck <s>] specfile
rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
package1 ... packageN
rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
rpm {--querytags}

Podr� encontrar m�s detalles acerca de la funci�n de estos parametros
en la p�gina del manual de RPM.

5. Y ahora, �qu� puedo hacer de verdad con RPM?

RPM es una herramienta potent�sima y, como puede ver, dispone de
varios par�metros. La mejor forma de apercibirse de ellas es
examinando unos cuantos ejemplos. Antes mostramos una
instalaci�n/desinstalaci�n sencilla, ahora van unos cuantos m�s:

� Supongamos que ha borrado unos cuantos ficheros por accidente, pero
no est� seguro de qu� es lo que ha borrado. Si quiere verificar
completamente su sistema y ver qu� se ha perdido, puede hacer:

rpm -Va

� Supongamos que se encuentra con un fichero que no reconoce. Para
saber a qu� paquete pertenece puede hacer:

rpm -qf /usr/X11R6/bin/xjewel

La salida podr�a ser:

xjewel-1.6-1

� Supongamos que acaba de hacerse con un nuevo paquete RPM de koules,
pero no sabe qu� puede ser. Para obtener informaci�n al respecto:

rpm -qpi koules-1.2-2.i386.rpm

La salida podr�a ser:

Name : koules Distribution: Red Hat Linux Colgate
Version : 1.2 Vendor: Red Hat Software
Release : 2 Build Date: Mon Sep 02 11:59:12 1996
Install date: (none) Build Host: porky.redhat.com
Group : Games Source RPM: koules-1.2-2.src.rpm
Size : 614939
Summary : SVGAlib action game with multiplayer, network, and sound support
Description :
This arcade-style game is novel in conception and excellent in execution.
No shooting, no blood, no guts, no gore. The play is simple, but you
still must develop skill to play. This version uses SVGAlib to
run on a graphics console.

� Ahora quiere saber qu� ficheros instala el paquete RPM. Puede
hacer:

rpm -qpl koules-1.2-2.i386.rpm

La salida es:

/usr/doc/koules
/usr/doc/koules/ANNOUNCE
/usr/doc/koules/BUGS
/usr/doc/koules/COMPILE.OS2
/usr/doc/koules/COPYING
/usr/doc/koules/Card
/usr/doc/koules/ChangeLog
/usr/doc/koules/INSTALLATION
/usr/doc/koules/Icon.xpm
/usr/doc/koules/Icon2.xpm
/usr/doc/koules/Koules.FAQ
/usr/doc/koules/Koules.xpm
/usr/doc/koules/README
/usr/doc/koules/TODO
/usr/games/koules
/usr/games/koules.svga
/usr/games/koules.tcl
/usr/man/man6/koules.svga.6

Estos son s�lo unos pocos ejemplos. Otros, a�n m�s creativos, podr�
hacerlos f�cilmente una vez que se haya familiarizado con RPM.

6. Construyendo paquetes RPM

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

El procedimiento b�sico es el siguiente:

� Aseg�rese que su /etc/rpmrc est� configurado para su sistema.

� H�gase con el c�digo fuente del software a empaquetar para ser
compilado en su sistema.

� Haga un parche con todos los cambios que ha tenido que realizar
para que los fuentes se compilen adecuadamente.

� Cree un fichero .spec para el paquete.

� Aseg�rese de que todo est� en su sitio.

� Construya el paquete usando RPM.

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

6.1. El fichero rpmrc

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

require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <[email protected]>

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

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

tmppath: /usr/tmp

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

La siguiente l�nea es la de distribution (-- N.T.: distribuci�n--) .
Puede definirla bien aqu� o bien en el fichero buena idea asegurarse
de que esta l�nea es correcta, incluso cuando no se requiera. La
l�nea de vendor (-- N.T.: distribuidor--)

funciona de la misma manera, aunque puede contener cualquier cosa
(ej.: Joe's Software and Rock Music Emporium).

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

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

rpm --showrc

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

6.2. El fichero spec

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

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

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

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

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

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

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

%files
%doc README COPYING ChangeLog

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

6.3. La Cabecera

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

� Summary: Descripci�n en una s�la l�nea del paquete.

� Name: La cadena que vaya a servir de nombre para el fichero rpm.

� Version: La cadena que vaya a ser el n�mero de versi�n para el
fichero rpm.

� Release: El n�mero de publicaci�n para un paquete dentro de un
mismo n�mero de versi�n (ej.: si crea un paquete y lo encuentra
ligeramente defectuoso y necesita generarlo de nuevo, el siguiente
paquete deber�a tener 2 como n�mero de publicaci�n).

� Icon: El nombre del icono que podr�n usar interfaces de instalaci�n
alto nivel (como Red Hat `glint''). Debe ser un fichero

� Source: Esta l�nea apunta a la localizaci�n HOME del fichero de
fuentes original. Se usa si alguna vez quiere tener los fuentes de
nuevo o chequear para nuevas versiones. Precauci�n: el nombre del
fichero en esta l�nea DEBE coincidir con el nombre que tiene tal
fichero en su sistema (ej.: no se haga con el fichero fuente y le
cambie el nombre). Puede especificar m�s de un fichero fuente de
esta forma:

Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz

Estos ficheros deben residir en el directorio SOURCES. (La estructura
de directorios es discutida en una secci�n posterior, ``El �rbol de
Directorios de las Fuentes'', ``'').

� Patch: El lugar donde podr�n encontrarse los parches si los
necesita de nuevo. Precauci�n: el nombre debe coincidir con el de
SUS propios parches. Puede especificar m�s de un fichero de parches
de esta forma:

Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch

Estos ficheros deben residir en el directorio SOURCES.

� Copyright: Hace referencia al modelo de copyright al que se acoje
el paquete. Puede tratarse de algo al estilo de GPL, BSD, MIT,
public domain (-- N.T.: dominio p�blico--) , distributable (--
N.T.: distribuible--) o commercial (-- N.T.: comercial--) .

� BuildRoot: Hace referencia a un directorio que simular� el ra�z (/)
para la construcci�n e instalaci�n de un nuevo paquete. Puede
usarlo para probar su paquete antes de instalarlo en su m�quina.

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

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

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

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

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

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

� -n nombre asignar� el nombre del directorio en construcci�n. Por
defecto es $NAME-$VERSI�N. Otras posibilidades incluyen $NAME,
${NAME}${VERSI�N}, o cualquiera que use el fichero tar principal.
(Aperc�bese de que estas variables ``$'' no son variables reales
dentro del fichero spec. S�lo se usan aqu� en lugar de un nombre
ejemplo. Necesitar� usar el nombre real y la versi�n de su paquete,
no una variable).

� -c crear� y cambiar� al directorio nombrado antes de desempaquetar
con tar.

� -b # desempaquetar� con tar el fichero fuente # antes de cambiar al
directorio (y esto no tiene sentido con -c, as� que no lo haga).
S�lo es �til cuando se usan varios archivos fuente.

� -a # desempaquetar� el fichero fuente # despu�s de cambiar al
directorio.

� -T Este par�metro anula la acci�n por defecto de desempaquetar el
fichero fuente y requiere
el fichero fuente principal. Necesitar� esto cuando hayan fuentes
secundarias.

� -D No borra el directorio antes de desempaquetar. S�lo resulta
�til cuando tenga m�s de una macro de configuraci�n. Deber�a ser
usado solamente en macros de configuraci�n despu�s de la primera
(pero nunca en la primera).

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

� # aplicar� el parche Patch#.

� -p # especifica el n�mero de directorios a evitar por el comando
patch(1).

� -P La acci�n por defecto es aplicar Patch (o Patch0). Este
par�metro inhibe dicha acci�n y requiere un 0 para tener
desempaquetado el fichero fuente principal. Esta opci�n resulta
�til en una segunda (o posterior) macro %patch que requiera
par�metros distintos a la primera macro.

� Tambi�n puede hacer %patch# en lugar de hacer el comando real:
%patch # -P
Estas deber�an ser todas las macros que necesite. En cuanto las tenga
claras, podr� crear cualquier otra configuraci�n que necesite mediante
guiones sh. Todo lo que incluya hasta la macro %build (discutida en la
siguiente secci�n) es ejecutado v�a sh. Busque en el ejemplo anterior
el tipo de cosas que puede querer incluir all�.

6.5. %build

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

6.6. %install

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

6.7. Guiones opcionales pre y post Install/Uninstall

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

� %pre es la macro para los guiones pre-instalaci�n.

� %post es la macro para los guiones post-instalaci�n.

� %preun es la macro para los guiones pre-desinstalaci�n.

� %postun es la macro para los guiones post-desinstalaci�n.

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

6.8. %files

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

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

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

� %doc se usa para se�alar los ficheros de documentaci�n del paquete
fuente que desea que sean instalados en una instalaci�n binaria. La
documentaci�n ser� instalada en
/usr/doc/$NOMBRE-$VERSI�N-$PUBLICACI�N. La lista podr� incluir
varios ficheros en una s�la l�nea o puede listarlos de forma
separada con una macro para cada uno de ellos.

� %config se usa para se�alar los ficheros de configuraci�n en un
paquete. Ficheros as� pueden ser sendmail.cf, passwd, etc. Si
posteriormente desinstala un paquete que incluye ficheros de
configuraci�n, todos los ficheros sin modificar ser�n borrados y
todos los ficheros modificados ser�n movidos a su nombre antiguo
con el sufijo .rpmsave a�adido a su nombre. Tambi�n puede incluir
m�ltiples ficheros con esta macro.

� %dir se�ala a un �nico directorio en la lista como propiedad de un
paquete. Por defecto, si incluye en la lista un nombre de
directorio SIN una macro %dir, TODO el contenido de ese directorio
es incluido en la lista de ficheros y posteriormente instalado como
parte del paquete.

� %files -f <nombredefichero> le permitir� tener la lista de ficheros
contenida en un fichero situado en el directorio de las fuentes.
Resulta �til en los casos en los que un paquete puede crear su
propia lista de ficheros por s� mismo. En ese caso s�lo tendr� que
incluir el nombre de ese fichero aqu� y no necesitar� especificar
nada m�s.

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

6.9. Construcci�n

6.9.1. ``El �rbol de Directorios de los Fuentes''

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

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

� BUILD es el directorio donde RPM lleva a cabo toda la construcci�n.
No tiene que llevar a cabo su prueba de construcci�n en ning�n
sitio en particular; aqu� es donde RPM llevar� a cabo la
compilaci�n y empaquetamiento.

� SOURCES es el directorio donde debe situar los ficheros fuente
originales y los correspondientes parches. Es donde RPM buscar� por
defecto.

� SPECS es el directorio donde deben ir situados los ficheros spec.

� RPMS es donde RPM dejar� los paquetes RPM binarios una vez
construidos.

� SRPMS es donde RPM dejar� los paquetes RPM fuentes.

6.9.2. Prueba de construcci�n

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

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

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

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

6.9.3. Creaci�n de la Lista de Ficheros

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

6.9.4. Construyendo el paquete con RPM

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

rpm -ba foobar-1.0.spec

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

� p obliga a ejecutar solamente la secci�n prep del fichero spec.

� l efect�a algunos chequeos en %files.

� c ejecuta la secci�n %prep y compila. Resulta �til cuando no est�
seguro de si sus fuentes compilan completamente. Puede parecer
in�til porque usted tal vez quiera jugar solamente con los fuentes
hasta que compilen y usar entonces RPM, pero una vez que se haya
acostumbrado a usar RPM, encontrar� ocasiones en las que podr�
usarla.

� i ejecuta las secciones prep, compile e install.

� b ejecuta las secciones prep, compile e install y construye el
paquete binario.

� a ejecuta las secciones prep, compile e install y construye los
paquetes binario y fuentes.

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

� --short-circuit El proceso de construcci�n comenzar� directamente
por la fase especificada, salt�ndose las previas a la indicada.
(S�lo puede ser empleado en conjunci�n con c e i).

� --clean elimina el �rbol de construcci�n una vez que ha concluido.

� --keep-temps mantendr� todos los ficheros temporales y los guiones
que estuvieran en /tmp. Podr� saber qu� ficheros fueron creados
all� usando el par�metro -v.

� --test No lleva a cabo ninguna fase realmente, pero mantiene todos
los ficheros temporales.

6.10. Prob�ndolo

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

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

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

6.11. �Qu� hacer con los nuevos paquetes RPM?

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

6.12. �Y ahora qu�?

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

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

7. Construcci�n multi-arquitectura de paquetes RPM

Ahora puede usarse RPM para construir paquetes para Intel i386,
Digital Alpha ejecutando Linux y Sparc. Tambi�n se ha informado de su
funcionamiento en estaciones de trabajo SGI y HP. Hay varias
caracter�sticas que hacen que la construcci�n de paquetes para todas
las plataformas sea f�cil. La primera de �stas es la directiva
``optflags'' del fichero /etc/rpmrc. Puede usarse para asignar las
opciones usadas durante la construcci�n del software con valores
espec�ficos de cada arquitectura. Otras son las macros ``arch'' en el
fichero spec. Pueden usarse para diferentes cosas, en funci�n de la
arquitectura para la que se est� construyendo. Otra m�s, es la
directiva ``Exclude'' de la cabecera.

7.1. Ejemplo de fichero spec

El siguiente es parte del fichero spec para el paquete ``fileutils''.
Est� configurado para compilar en Alpha e Intel.

Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 1
Copyright: GPL
Group: Utilities/File
Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch

%description
These are the GNU file management utilities. It includes programs
to copy, move, list, etc, files.

The ls program in this package now incorporates color ls!

%prep
%setup

%ifarch alpha
%patch -p1
autoconf
%endif
%build
configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s

%install
rm -f /usr/info/fileutils*
make install
gzip -9nf /usr/info/fileutils*

7.2. Optflags

En este ejemplo puede ver c�mo se usa la directiva ``optflags'' desde
el fichero /etc/rpmrc. En funci�n de la arquitectura para la que est�
construyendo, el valor adecuado lo proporciona RPM_OPT_FLAGS. Debe
parchear el fichero Makefile de su paquete para usar esta variable en
lugar de las directivas normales que puede usar (como -m486 y -O2).
Tendr� una mejor perspectiva de lo que necesita hacer instalando este
paquete de fuentes, desempaquetando el fichero tar con los fuentes y
examinando el fichero Makefile. Examine el parche para el Makefile y
compruebe qu� cambios son necesarios realizar.

7.3. Macros

La macro %ifarch es muy importante para todo esto. La mayor�a de las
veces necesitar� hacer un parche o dos espec�ficos para una s�la
arquitectura. En ese caso, RPM le permitir� aplicar ese parche s�lo
para una arquitectura.

En el ejemplo anterior, fileutils tiene un parche para m�quinas de 64
bits. Obviamente, s�lo tiene aplicaci�n en Alpha, por el momento.
Entonces, a�adimos una macro %ifarch al parche de 64 tal como:

%ifarch axp
%patch1 -p1
%endif

Esto asegurar� que el parche no es aplicado en cualquier arquitectura
excepto en Alpha.

7.4. Excluyendo arquitectura de los paquetes.

A la vez que puede tener fuentes RPM en un s�lo directorio para todas
las plataformas, hemos implementado la posibilidad de ``excluir''
paquetes para que no sean construidos en ciertas arquitecturas. Debido
a esto, puede hacer cosas como:

rpm --rebuild /usr/src/SRPMS/*.rpm

y conseguir construir los paquetes adecuados. Si todav�a no ha portado
una aplicaci�n a una determinada plataforma, todo lo que tiene que
hacer es a�adir una l�nea como:

ExcludeArch: axp

a la cabecera del fichero spec del paquete de fuentes. Reconstruya
entonces el paquete sobre la plataforma para la que est� preparado.
Como resultado tendr� disponible un paquete compilable sobre Intel
pero que es f�cilmente omitible sobre Alpha.

7.5. Acabando

Usar RPM para crear paquetes para m�ltiples arquitecturas es
generalmente m�s sencillo de hacer que conseguir que el paquete
compile por s� mismo en todos los casos. Como siempre, la mejor ayuda
disponible cuando uno se queda bloqueado al construir un paquete RPM
es examinar un paquete de fuentes similar.

8. Copyright

Este documento y sus contenidos est�n protegidos por las leyes de
propiedad intelectual. Se permite la redistribuci�n de este documento
siempre que sus contenidos permanezcan intactos y sin cambios. En
otras palabras, solamente lo puede reformatear, reimprimir o
redistribuir.

9. Anexo: El INSFLUG

El INSFLUG forma parte del grupo internacional Linux Documentation
Project, encarg�ndose de las traducciones al castellano de los Howtos
(Comos), as� como la producci�n de documentos originales en aquellos
casos en los que no existe an�logo en ingl�s.

En el INSFLUG se orienta preferentemente a la traducci�n de documentos
breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs.
:) ), etc.

Dir�jase a la sede del INSFLUG para m�s informaci�n al respecto.

En la sede del INSFLUG encontrar� siempre las �ltimas versiones de las
traducciones: www.insflug.org. Aseg�rese de comprobar cu�l es la
�ltima versi�n disponible en el Insflug antes de bajar un documento de
un servidor r�plica.

Se proporciona tambi�n una lista de los servidores r�plica (mirror)
del Insflug m�s cercanos a Vd., e informaci�n relativa a otros
recursos en castellano.

Francisco Jos� Montilla, [email protected].