Los paquetes RPM de SUSE están firmados con GnuPG:

1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de>
Key fingerprint = 79C1 79B2 E1C8 20C1 890F  9994 A84E DAE8 9C80 0ACA

El siguiente comando permite comprobar la firma de un paquete RPM para averiguar si este realmente fue hecho por SUSE o por otra entidad de confianza:

rpm --checksig apache-1.3.12.rpm

Este procedimiento se recomienda especialmente con los paquetes de actualización de Internet. Nuestra clave pública para firmar los paquetes se encuentra por defecto en /root/.gnupg/. Desde la versión 8.1, esta clave también se incluye en el directorio /usr/lib/rpm/gnupg/ para que los usuarios normales también puedan comprobar la firma de los paquetes RPM.

Por lo general la instalación de un archivo RPM se realiza rápidamente:

rpm -i paquete.rpm

Este comando estándar solamente instala un paquete si se cumplen todas las dependencias, ya que de lo contrario podrían aparecer conflictos; los mensajes de error de rpm indican los paquetes que faltan para cumplir con las dependencias. La base de datos se ocupa de evitar conflictos: normalmente un archivo debe pertenecer a un solo paquete; también hay diferentes opciones que permiten pasar por alto esta regla, pero se debe estar muy seguro de ello ya que se puede perder la posibilidad de actualizar el paquete.

Algunas opciones muy interesantes para la actualización de un paquete son -U o --upgrade y -F o --freshen.

rpm -F paquete.rpm

Por medio de este comando se borra la antigua versión de un paquete y se instala la nueva. La diferencia entre ambas opciones radica en que en el caso de -U también se instalan paquetes que hasta ahora no estaban disponibles en en el sistema, mientras que la opción -F sólo actualiza un paquete que ya estuviera instalado. Por su parte, rpm trata los archivos de configuración con cuidado, apoyándose en la siguiente estrategia:

Después de la actualización se deben borrar los archivos .rpmorig, .rpmsave y .rpmnew para que estos no obstaculicen la siguiente actualización. La extensión .rpmsave se selecciona cuando la base de datos RPM ya conoce el archivo, en caso contrario se usa .rpmorig. Dicho en otras palabras, los “.rpmorig” se generan cuando se actualizan paquetes que no tienen formato RPM y los .rpmsave se generan actualizando paquetes RPM antiguos con RPM nuevos. La extensión .rpmnew se usa cuando no se puede determinar si el administrador de sistema realmente modificó el archivo de configuración o no. Puede encontrar una lista de estos archivos en /var/adm/rpmconfigcheck.

Compruebe que no se sobreescriben determinados archivos de configuración (como /etc/httpd/httpd.conf), para posibilitar una inmediato funcionamiento con las propias opciones de configuración.

Así pues, la opción -U (update) es algo más que una equivalencia de la secuencia -e (desinstalar/eliminar) e -i (instalar). Siempre que sea posible, es preferible usar la opción -U.

	Importante
Después de cada actualización es necesario controlar las copias de seguridad con las extensiones .rpmorig o .rpmsave generados por rpm. En caso de necesidad transfiera sus ajustes a los nuevos archivos de configuración y elimine después los antiguos con las extensiones .rpmorig o .rpmsave.

Al ejecutarlo con la opción -i, YaST puede resolver todas las interdependencias de paquetes y llevar a cabo la instalación:

yast -i paquete

Para eliminar un paquete se procede de la siguiente manera:

rpm -e paquete

rpm sólo borra un paquete en caso de no existir ninguna dependencia. Por lo tanto no es posible suprimir por ejemplo Tcl/Tk si todavía existe algún programa que lo necesite para su ejecución; esta funcionalidad se debe al control por parte de la base de datos RPM. Si en algún caso excepcional no es posible eliminar un paquete aunque haya dejado de existir toda dependencia, es probable que el problema se resuelva al generar de nuevo la base de datos RPM, usando la opción --rebuilddb.

Para garantizar la seguridad en la operación de un sistema es necesario instalar periódicamente en el sistema paquetes que lo actualicen. Hasta ahora, un fallo en un paquete sólo podía ser resuelto sustituyendo el paquete entero. En el caso de paquetes grandes con fallos pequeños, podemos encontrarnos rápidamente ante una gran cantidad de datos. A partir de la versión 8.1, SUSE ha incorporado una nueva función a RPM que permiten instalar parches en paquetes.

La información más interesante sobre un parche RPM se mostrará tomando como ejemplo al programa pine:

Puede obtener más información sobre RPM (incluyendo las prestaciones de los parches) en las páginas del manual de rpm y rpmbuild.

La opción -q (query) permite enviar consultas a los archivos RPM (opción -p archivo_paquete), así como a la base de datos RPM. El tipo de información a consultar depende de las opciones que figuren en la tabla 2.2, “Las opciones de consulta más importantes (-q [-p] paquete)”.

El siguiente comando produce como resultado la salida en pantalla 2.2, “rpm -q -i wget”:

rpm -q -i wget

Name        : wget                    Relocations: (not relocateable)
Version     : 1.8.1                   Vendor: SuSE AG, Nuernberg, Germany
Release     : 142                     Build Date: Mon Apr 5 16:08:13 2004
Install date: Mon Apr 5 13:54:08 2004 Build Host: xyz.suse.de
Group       : Productivity/Networking/Web/Utilities   
Source RPM  : wget-1.8.1-142.src.rpm
Size        : 2166418                     License: GPL
Packager    : feedback@suse.de
Summary     : A tool for mirroring FTP and HTTP servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This might be done in script files or via command line.
[...]

La opción -f sólo funciona cuando se indica el nombre de archivo completo con la ruta incluida; se pueden indicar tantos archivos como se desee. Por ejemplo el comando:

rpm -q -f /bin/rpm /usr/bin/wget

produce como resultado:

rpm-3.0.3-3
wget-1.5.3-55

Si sólo se conoce una parte del nombre del archivo, se puede obtener ayuda mediante un script (ver el archivo 2.3, “Script de búsqueda de paquetes”) al cual se pasa como parámetro el nombre del archivo buscado.

#! /bin/sh
for i in $(rpm -q -a -l | grep  $1); do
    echo "\"$i\" está en el paquete:"
    rpm -q -f $i
    echo ""
done

Con el siguiente comando se puede ver información detallada (actualizaciones, configuración, cambios, etc.) sobre determinados paquetes; en este ejemplo sobre el paquete rpm:

rpm -q --changelog rpm

No obstante, sólo se muestran las últimas 5 entradas de la base de datos RPM, el paquete en sí contiene todas las entradas (de los últimos 2 años) – la siguiente consulta funciona si el CD 1 está montado en /cdrom:

rpm -qp --changelog /cdrom/suse/i586/rpm-3*.rpm

La base de datos instalada también permite efectuar verificaciones. Estas se introducen con la opción -V (equivalente a -y o --verify). Con la verificación, rpm muestra todos los archivos del paquete que han sido modificados desde su instalación original. rpm coloca hasta ocho caracteres por delante del nombre de archivo que indican los siguientes cambios:

Para los archivos de configuración aparece como valor adicional la letra c, como lo muestra el ejemplo para el archivo /etc/wgetrc de wget, que ha sido modificado:

rpm -V wget
S.5....T c /etc/wgetrc

Los archivos de la base de datos RPM se encuentran en /var/lib/rpm.

Estos pueden ocupar hasta 30 MB en una partición /usr de 1 GB, especialmente después de una actualización completa. Si la base de datos parece demasiado grande, se puede reducir su tamaño usando la opción --rebuilddb. Antes de reconstruir la base de datos se debe hacer una copia de seguridad de la base de datos existente.

El script cron cron.daily genera diariamente copias comprimidas de la base de datos y las guarda en /var/adm/backup/rpmdb. El número de estas copias está definido por la variable MAX_RPMDB_BACKUPS, cuyo valor por defecto es 5, pero se puede modificar en /etc/sysconfig/backup. Cada backup ocupa aproximadamente 3 MB en una partición /usr de 1 GB.

Todos los paquetes fuente (sources) tienen la extensión .src.rpm; estos archivos se llaman “Source-RPMs”.

	Sugerencia
Los paquetes con fuentes se pueden instalar con YaST como cualquier otro paquete, con la diferencia que estos no se marcan como instalados, con una [i], como ocurre con los paquetes ordinarios. Por esta razón los paquetes fuente no figuran en la base de datos RPM, ya que este sólo anota el software instalado.

Si no hay ninguna configuración personal activada (por ejemplo a través del archivo /etc/rpmrc), los directorios de trabajo de rpm o rpmbuild deben existir en /usr/src/packages. Dichos directorios son:

Al instalar con YaST un paquete de fuentes, todos los componentes necesarios para el proceso build se copian en el directorio /usr/src/packages: Las fuentes y los parches se van al directorio SOURCES y el archivo­-.spec correspondiente se copia en el directorio SPECS.

	Importante
No haga experimentos con RPM y componentes importantes del sistema como pueden ser glibc, rpm, sysvinit etc.: la operatividad de su sistema está en juego.

Tomando como ejemplo el paquete wget.src.rpm, después de ser instalado con YaST, aparecerán los siguientes archivos:

/usr/src/packages/SPECS/wget.spec
/usr/src/packages/SOURCES/wget-1.4.5.dif
/usr/src/packages/SOURCES/wget-1.4.5.tar.gz

Con el comando rpmbuild -b X /usr/src/packages/SPECS/wget.spec comienza la compilación. La variable X puede representar diferentes pasos, de los cuales aquí figuran algunos (ver también la ayuda que aparece con la opción --help o la documentación de RPM):

La opción --short-circuit permite saltarse determinados pasos. El RPM binario se instala finalmente con rpm -i o mejor aún con rpm -U.

En el caso de muchos paquetes se corre el riesgo de que se instalen archivos no deseados en el sistema. Para evitarlo se puede emplear el paquete build, el cual crea un entorno definido dentro del que se contruye el paquete. Para crear este entorno chroot, se debe proporcionar un árbol completo de paquetes al script build, ya sea en el disco duro, mediante NFS o desde un DVD. La ubicación concreta se comunica al script por medio del comando build --rpms <ruta>. A diferencia de rpm, el comando build quiere tener el archivo SPEC en el mismo directorio que las fuentes. Para volver a compilar wget en el ejemplo superior con el DVD montado en el sistema en /media/dvd, ejecute los siguientes comandos como usuario root:

cd /usr/src/packages/SOURCES/ 
mv ../SPECS/wget.spec . 
build --rpms /media/dvd/suse/ wget.spec

A continuación se creará en /var/tmp/build-root un entorno mínimo donde se construirá el paquete. Los paquetes resultantes se almacenarán posteriormente en /var/tmp/build-root/usr/src/packages/RPMS

El script build ofrece además otras opciones. Así, se puede definir la utilización de los propios RPMs frente al resto, omitir la iniciación del entorno build o restringir el comando rpm a una de las fases descritas anteriormente. Puede obtener más información con el comando build --help y en |refman[1]build.

El Midnight Commander (mc) puede mostrar el contenido de un archivo RPM y copiar partes de él. El archivo RPM se muestra en un sistema de archivos virtual para el cual se ponen a disposición todas las opciones del menú del mc. La información de los encabezamientos del archivo HEADER se visualiza con F3; con las teclas del cursor y Intro se puede “navegar” por la estructura del archivo y en caso de necesidad, copiar componentes usando F5. – Por otra parte, ya existe rpm.el para Emacs, el cual es un frontal para rpm.

KDE™ incluye la herramienta kpackage. En GNOME™ se incluye gnorpm.

Alien (alien) permite la conversión de los formatos de las distintas distribuciones. Con este programa se puede intentar convertir, antes de la instalación, los archivos antiguos del tipo TGZ al formato RPM, para que la base de datos RPM reciba durante la instalación la información de los paquetes. Pero cuidado: alien es un script de Perl y según sus autores todavía se encuentra en fase alfa, aunque ya ha alcanzado un número de versión bastante alto.