Sorpresa! Red Hat 7.0 presenta RPM 4.0, incompatible con el RPM 3.0.x que usan todas las demás distribuciones anteriores basadas en el RedHat Package Manager. ¿La única solución es actualizar completamente nuestra distribución actual? Afortunadamente, no. Pero pasarnos a RPM 4.0 es sólo el principio, si queremos mantenernos actualizados con los últimos paquetes de software. Estas son las herramientas que nos ayudarán a conseguirlo.
Apenas conseguí una copia de Red Hat 7.0, mi primer impulso fué el mismo que había tenido con todas las versiones anteriores de Red Hat al momento de su lanzamiento: repasar todos los nuevos paquetes de software incluidos, buscando descubrir cuáles se habían incorporado y cuáles otros se habían actualizado. Mi idea siempre fué evaluar si esta nueva versión incorporaba suficientes cambios significativos como para justificar una completa actualización de mi distribución actual (HispaFuentes 7.0). Desafortunadamente para cuando comencé a hacer esto, ya comenzaba a anunciarse en la red que Red Hat 7.0 era una de las distribuciones Linux con más errores y fallas de seguridad que se habían visto hasta ahora. Aunque aquellos anuncios tenían un grado de veracidad relativo por tratarse recién de una versión punto cero, lo innegable es que cualquier nueva versión de Red Hat marca la pauta que seguirán todas las demás distribuciones basadas en ella (que no son pocas), las que tomarán minuciosa nota de sus aciertos y fallas para las próximas versiones de las suyas propias.
Con esto último en mente, ya había decidido postergar (nuevamente) la actualización de mi sistema a Red Hat; pero por lo menos esperaba sacar ventaja de la gran cantidad de software incluído en los 2 CDs de su versión GPL para actualizar algunos de mis paquetes más importantes o de uso más frecuente. Como siempre, aprovechando la excelente facilidad de Midnight Commander para ver dentro del contenido de los paquetes .RPM antes de instalarlos, traté de leer las descripciones de aquellos que más me interesaba instalar, para conocer qué grandes cambios habían tenido y leer cualquier notificación sobre sus nuevas características que pudieran tener, o por lo menos esa fué mi intención... Mi sorpresa fué enorme al descubrir que Midnight Commander no podía consultar los nuevos paquetes .RPM de Red Hat 7.0, y lo mismo ocurría al hacerlo desde una terminal usando las opciones correspondientes del mismo rpm.
[PAGEBREAK]
RPM 4.0
La explicación resultó obvia cuando descubrí en el CD#1 el paquete rpm-4.0-4.i386.rpm. Red Hat 7.0 había introducido por primera vez en una distribución Linux una nueva versión su RedHat Package Manager. Y como era de esperarse, todos los paquetes de software que incluía estaban empaquetados con RPM 4.0, que además resultaba ser incompatible con RPM 3.0.x, la versión que incluyen todas las distribuciones Linux anteriores a Red Hat 7.0. El problema parecía aún más serio cuando encontré que las nuevas versiónes de los paquetes disponibles en sus sitios de Internet no siempre incluían uno empaquetado para RPM 3.0.x, una tendencia que indiscutiblemente continuará en el furturo cercano.
Por supuesto, cambios introducidos por RPM 4.0 con respecto a su versión anterior 3.0.6 resultan tantos y tan drásticos como para justificar su cambio de numeración. Uno de los importantes es el cambio del formato de su base de datos, donde se guarda la información correspondiente a los paquetes instalados y sus dependencias, de la db2 usada por RPM 3.0.x a la nueva db3.
Siendo Red Hat y las demás distribuciones Linux basadas en ella y/o compatibles con RPM, la enorme mayoría de las distribuciones usadas hoy en día, actualizar la nuestra a RPM 4.0 es una inversión para la longevidad de nuestro sistema. Podemos hacer esto actualizando nuestra distribución completamente a Red Hat 7.0 o alguna otra más reciente, con todo el contratiempo que implica instalar una nueva distribución, o bien actualizar únicamente los paquetes que involucran a RPM. Personalmente, después de semanas para lograr configurar mi HispaFuentes 7.0 casi completamente a mis necesidades, y justo cuando estoy comenzando a disfrutar de mi escritorio Linux personalizado, me inclino más por esta última alternativa.
[PAGEBREAK]
Paquetes RPM 3.0 de RPM 4.0
Con RPM actualizar cualquier paquete .rpm instalado en nuestro sistema por uno más nuevo es tan fácil como escribir rpm -Uvh nuevo-paquete, incluso para componentes tan vitales como el compilador, las librerías y el mismo RPM. Pero por supuesto, el paquete rpm-4.0-4.i386.rpm incluído en Red Hat 7.0 está empaquetado con RPM 4.0 (¿Se acuerdan del problema del huevo y la gallina?) y nosotros todavía tenemos instalado el viejo RPM 3.0.x. Debemos conseguir entonces un paquete binario de RPM 4.0 empaquetado con RPM 3.0.x para actualizarlo correctamente en nuestra distribución. Los paquetes que necesitamos son los siguientes (los números de versión pueden cambiar desde que escribí esto), y todos pueden bajarse de RPM.org:
Después de bajarlos, el proceso de instalación es irrisoriamente sencillo, podemos comenzar a actualizar los ya instalados (para el caso de los 3 primeros) o instalarlos como cualquier paquete nuevo (para los 2 últimos):
rpm -Uvh rpm-4.0-6x.i386.rpm ... rpm -ivh db3-3.1.14-0.3.6x.i386.rpm
Para comprobar si la actualización se llevó a cabo correctamente podemos verificar la versión de RPM que tenemos instalada en cualquier momento con rpm --version. Es muy importante que instalemos los paquetes db3, ya que aunque la actualización se haya llevado a cabo exitosamente, la base de datos RPM de nuestro sistema sigue estando en el viejo formato db2. La conversión al nuevo formato db3 se realiza con el comando rpm --rebuilddb
Con esto ya deberíamos tener nuestro flamante RPM 4.0 instalado y listo para correr. RPM 4.0 es compatible hacia atrás con RPM 3.0.x, o sea que cualquier paquete que nos haya quedado sin instalar de nuestra distribución actual es todavía perfectamente compatible. Pero claro, la idea principal es poder instalar los últimos paquetes disponibles en los CDs de Red Hat 7.0 y en la red, sin tener que preocuparnos sobre con qué versión de RPM fueron empaquetados. Lo que nos lleva a nuestro próximo tema.
[PAGEBREAK]
Cómo mantener nuestros RPMs actualizados
Aunque Red Hat 7.0 es la última versión de esta distribución (al momento de escribir esto), para el momento que llegue a nuestras manos una gran parte de los paquetes que incluye ya estarán desactualizados con respecto a la versión que de ellos será posible encontrar en la red. Encontrarlos es el desafío, ya que RPM por sí sólo no incluye ningún medio para hacer este trabajo automáticamente. Algunos quizás piensen que esto sería demasiado pedir, a ellos les recuerdo que los usuarios de Debian cuentan para esa tarea con una excelente herramienta llamada apt-get, que puede buscar, bajar e instalar los últimos paquetes .deb para su distribución de una manera totalmente transparente. Es por ello que sus usuarios no se preocupan demasiado porque el Proyecto Debian lance sólo una nueva versión de su distribución cada año o menos frecuentemente. Y es por utilidades como apt-get que Debian es considerada como una de las distribuciones mejor actualizadas.
Los usuarios de distribuciones basadas en Red Hat o RPM todavía no contamos con una utilidad similar a apt-get, principalmente debido a que apt-get es relativamente más reciente que RPM. Sin embargo ya existen intentos para remediar esta notable falta. Uno de los más reconocidos es RPMFind.
RPMFind es un práctico utilitario para consultar los paquetes disponibles en el servidor de rufus.w3.org, uno de los más grandes repositorios de paquetes RPM de la red. Lo verdaderamente interesante de RPMFind es su capacidad para tener en cuenta las dependencias de los paquetes que buscamos, y permitirnos bajar no sólo un paquete en particular, sino todos los que sean necesarios para instalarlo correctamente. A pesar de que el servidor de RPMFind es uno solo, cuenta con varios mirrors en todo el mundo, por lo que su disponibilidad está prácticamente asegurada siempre.
Aunque los servidores de RPMFind pueden ser un buen primer lugar para comenzar nuestra búsqueda, no hay garantía de que los paquetes que encontremos allí sean los últimos; pero por lo menos RPMFind se incluye prácticamente con todas las distribuciones Linux basadas en RPM. RPMFind no está específicamente diseñada para ninguna distro en particular, y por lo tanto podemos reconocerla como la única solución estándar disponible en este momento. Lo que nos lleva a nuestro próximo tema.
[PAGEBREAK]
Las distros hacen su parte
Red Hat 7.0 también introdujo Red Hat Network (RHN) un nuevo servicio para la actualización automática del sistema que funciona en background como un demonio más, llamado rhnsd. Todo sistema registrado en la Red Hat Network tiene su propio perfil en los servidores de Red Hat, y cada vez que un nuevo paquete de software está disponible, el administrador tiene la posibilidad de bajarlo e instalarlo automáticamente. Aunque el software para correrlo se incluye en todo Red Hat 7.0, este servicio sólo es gratuito por los primeros meses de uso, y peor aún, sólo funciona con esa versión de Red Hat. Sin duda muchos administradores serán renuentes a permitir semejante intromisión en sus sistemas, sin embargo, esta alternativa quizás sea más atractiva para los usuarios individuales (que puedan costearse el servicio). Es evidente entonces que RHN en su estado actual no es la solución definitiva al problema, y mientras las ambiciones económicas guíen el desarollo de Red Hat, esta situación no cambiará.
Por otro lado, Conectiva está trabajando en aptitude, un proyecto cuya finalidad es portar la funcionalidad de apt a otras distribuciones basadas en paquetes RPM. aptitude se presentará, teóricamente, en su próximo Conectiva 6.0, aunque ya es posible bajarse sus primeras versiones preliminares de su FTP. Al contratio que RHN este proyecto se presenta como un intento más serio según los principios de GNU/Linux, así que nuestras expectativas para él son mucho más grandes. Bien por Conectiva.
Mandrake tiene su propia solución al problema, se llama Mandrake-Update, oficialmente introducida en Linux-Mandrake 7.1, y su alcance se extiende a todo el sistema. La actualización de paquetes se realiza desde FTPs cerficados, basándose en la versión de nuestra distribución para sugerir actualizaciones de seguridad, correcciones de errores, desarrollo, etc. Linux-Mandrake también cuenta con RPMDrake, su instalador tipo KPackage o GnoRPM, que además de instalar un paquete también resuelve el (gran) problema de las dependecias, es decir, cuáles paquetes son necesarios instalar antes del que nos interesa. Sus interfaces son bastante prácticas y fáciles de usar, pero Mandrake-Update y RPMDrake sólo están disponibles para los usuarios de Linux-Mandrake, y depende de que sus desarrolladores compilen para su distribución los últimos paquetes de nuestro entorno gráfico favorito, entre otros tantos. Lo que nos lleva a nuestro próximo tema.
[PAGEBREAK]
Helix no se queda atrás
A nivel de los entornos gráficos el avance más importante es, sin duda, Helix Code Update, incluído en cualquier escritorio Helix/GNOME de cualquier distribución (a excepción de Debian). Helix Code Update se conecta al servidor de Helix o cualquiera de sus mirrors alrededor de todo el mundo y recupera una lista con las últimas actualizaciones de los paquetes que lo componen, sugiriendo las actualizaciones que se apliquen en ese momento, por orden de prioridad. Afortunadamente no es necesario que bajemos todos lo paquetes sugeridos, aunque es un buena idea mantener por lo menos los componentes escenciales actualizados. Los paquetes que elijamos actualizar se bajarán y actualizarán automáticamente, y los cambios se reflejarán incluso en los menúes del escritorio.
Por el lado bueno, el escritorio Helix/GNOME es tan completo que esta herramienta de actualización quizás sea la última que lleguemos a necesitar. Por el lado malo, Helix Code Update sólo afecta a los componentes de su escritorio, dejando de lado otras importantes partes de GNU/Linux, como el kernel.
El futuro de Helix Code Update se llama Red Carpet y supuestamente será parte de GNOME 1.4, que además brindará no sólo servicios de actualización de software, sino otros orientados al usuario final, como el almacenamiento remoto de información personal. La veta comercial de Red Carpet pasará por ofrecer su servicio de distribución de software a otras empresas, y la posibilidad de una suscripción mensual para servicios adicionales.
Hasta donde tengo conocimiento, no existe algo similar en KDE o en cualquier otro entorno gráfico, lo que sin duda pone a Helix/GNOME un paso adelante, por lo menos en este aspecto! :) Sin embargo, ninguna de todas las alternativas expuestas está lo suficientemente madura como para reemplazar a las otras. Lo que nos lleva a nuestra conclusión.
[PAGEBREAK]
Conclusión
No hay duda de que el RedHat Package Manager ha sido un enorme avance para la administración del software instalado en un sistema Linux, y que ha jugado un importante papel en la acepción de un formato para la distribución de aplicaciones casi estándar, abierto y libre, que muchos han sabido adoptar y algunos están en proceso de mejorar. Sin embargo, a medida que Linux evoluciona en un sistema más completo y complejo, comienzan a hacerse evidentes sus faltas y puntos débiles. Está claro que RPM 4.0 sólo ha sido una actualización evolutiva, más no revolucionaria, y que la próxima generácion del Administrador de Paquetes RedHat deberá integrarse con Internet, no depender de ninguna distribución en particular, ser conciente de nuestro entorno gráfico y cumplir todas las condiciones de la licencia GNU/GPL: ser libre y de código abierto. Sólo que esta vez, puede ser que el próximo gran avance en la actualización de un sistema GNU/Linux basado en paquetes RPM no lo dé Red Hat.
Links