2.1.1.- Distribuciones y convencines de RPM

red_hat_logo_big-272x300Red Hat desarrolló RPM para su propia distribución. Pero Red Hat lanzó el software bajo GPL (General Public License, Licencia Pública General), por lo que se permitió a terceros utilizarlo libremente en sus propias distribuciones y eso fue precisamente lo que ocurrió. Algunas distribuciones, como Mandriva (antes conocida como Mandrake) al igual que otras partes de la distribución RPM. Obviamente, todas las distribuciones Linux comparten muchos componentes comunes, por lo que incluso los que no estaban basados originalmente den Red Hat se han ido separando de esta con el tiempo. Como consecuencia, el grupo de distribuciones que utilizan RPM muestra una variabilidad considerable, pero todas siguen siendo distribuciones de Linux. que proporcionan las mismas herramientas básicas, como el kernel de Linux, las consolas comunes, un servidor X, etc.

NOTA.- Red Hat se ha dividido en dos distribuciones: Fedora es la versión descargable preferida por los usuarios particulares, los estudiantes y las empresas con presupuesto limitado. El nombre Red Hat está reservado actualmente para la versión de pago de la distribución, que es conocida oficialmente como red Hat Enterprise Linux (RHEL).

RPM es una herramienta independiente de la plataforma. Como indicamos anteriormente, algunos sistemas distintos de Linux pueden utilizar RPM, aunque la mayoría no lo emplean como su principal sistema de distribución de paquetes, RPM admite cualquier arquitectura de CPU: x86, x86-64 (conocida también como AMD64 y EM64T), IA-64, Alpha y SPARC. de entre las distribuciones anteriormente mencionadas, Yellow Dog es una distribución PowerPC. En su mayor parte, los RPM se pueden llevar a varias arquitecturas y, por lo tanto, no necesitan ser recompilados. También existen documentación y paquetes de configuración que funcionan en cualquier CPU.

La convención para nombrar paquetes RPM es la siguiente:

packgename-a.b.c-x.arch.rpm

Cada componente del nombre de fichero posee un significado especifico.

  • Nombre del paquete.- El primer componente (packagename) es el nombre del paquete como, por ejemplo, samba o samba-server para el fichero y el servidor de impresión de Samba. Tenga en cuenta que el mismo programa puede recibir distintos nombres de paquetes dependiendo de quien mantenga la distribución.
  • Número de versión.- El segundo componente (a.b.c) es el número de versión del paquete como, por ejemplo, 3.0.25b. No tiene que estar formado por números separados por comas, aunque ésta es su forma más común. El autor del programa es quien asigna el número de versión.
  • Número de compilación.- El número que sigue al número de versión (x) es el número de compilación (build number, también conocido como el número de edición, release number). Este número representa cambios menores realizados por el mantenedor del paquete,  no por el autor del programa. Estos cambios pueden ser script de inicio o ficheros de configuración alterados, ubicaciones de ficheros que han cambiado o parches añadidos al programa original para corregir errores o hacer que el programa sea más compatible con la distribución Linux objetivo. Muchos mantenedores de distribuciones añaden un código de letras al número de compilación para distinguir sus paquetes entre sí. Tenga en cuanta que estos números no se pueden comparar entre mantenedores de paquetes; la compilación número 5 de Pedro no es necesariamente una mejora de la compilación número 4 de Susan para el mismo paquete.
  • Arquitectura.- El componente final que precede a la extensión .rpm (arch) es un código de la arquitectura del paquete. La arquitectura i386 es la más común; representa un fichero compilado para cualquier CPU x86, de la 80386 en adelante. Algunos paquetes incluyen optimizaciones para Pentium o superiores (i586 o i686) y los paquetes binarios que no sean para x86 utilizan códigos para sus CPU, como ppc para CPU PowerPC o x86_64 para la plataforma x86-64. Los scripts,  la documentación y otros paquetes independientes de la CPU suelen utilizar el código de arquitectura noarch. La excepción principal a esta regla es el RPM fuente, que utiliza el código de arquitectura src. Podemos renombrar un paquete como se desee; ello no afectará a su instalación y funcionamiento. La información del nombre del fichero se conserva con el paquete. Este hecho puede resultar útil si se ve forzado a transferir las RPM utilizando un medio que no permita nombres largos para los ficheros. de hecho, las primeras versiones de SUSE evitaban los nombres largos, prefiriendo nombres cortos como samba.rpm. Cualquier paquete RPM se instalaría y ejecutaría en cualquier distribución de tipo RPM que empleara un tipo de CPU apropiado. Lamentablemente, de vez en cuando pueden surgir problemas de compatibilidad, entre los que se incluyen:
    • Las distribuciones pueden utilizar diferentes versiones de las utilidades RPM de una distribución sea utilizada en otra.
    • Los paquetes RPM diseñados para una distribución pueden tener dependencias que no se satisfacen en otra distribución. Un paquete puede requerir que una nueva versión de una biblioteca de la que esté presente en la distribución utilizada, por ejemplo. Este problema se puede resolver, generalmente, instalando o actualizando el paquete del que se depende, pero, en ocasiones, origina problemas debido a que la actualización puede romper otros paquetes. Es frecuente resolver estos problemas al recompilar el paquete deseado para instalarlo desde un RPM fuente, pero, a veces, el código fuente subyacente también necesitan las bibliotecas actualizadas.
    • Un paquete RPM se puede compilar para depender de un paquete con un nombre particular, como samba-client, que depende de samba-common; pero si la distribución que utiliza ha llamado al paquete de manera diferente, la utilidad rpm protestará. Puede invalidar esta objeción empleando el modificador --nodeps, pero, a veces, el paquete no funcionará una vez instalado. Al volver a compilar desde un RPM fuente se puede corregir corregir este problema o puede que no.
    • A pesar de que parezca satisfacerse una dependencia, las distintas distribuciones pueden incluir ficheros ligeramente distintos en sus paquetes. Por este motivo, un paquete echo para una distribución puede no ejecutarse correctamente al ser instalado en otra. A veces, se soluciona este problema instalando un paquete adicional.
    • Algunos programas incluyen scripto ficheros de configuración específicos para la distribución. Este problema es especialmente apropiado para los servidores, que pueden incluir scripts de inicio que van en /etc/rc.d/init.d o cualquier otra parte. La solución a este problema pasa por eliminar el script problemático tras instalar el RPM y, o bien iniciar el servidor de algún modo, o bien escribir un nuevo script de inicio, tomando quizá como modelo uno que venga con algún otro servidor para su distribución.

     

En la mayoría de los casos, es preferible utilizar los RPM pensados para su distribucitimthumbón. Los  meta-empaquetadores RPM, como YellowDog Updater Modified (Yum), pueden simplificar la localización e instalación de paquetes diseñados para su distribución. Si se ve forzado a salirse de la lista de paquetes soportados oficialmente en su distribución,para la mayoría de los programas la mezcla de RPM de diferentes distribuciones suele funcionar razonablemente bien. Esto es particularmente cierto si las distribuciones están estrechamente relacionadas o si recompila desde un RPM fuente. Pero, si tiene problemas con un RPM, puede que haga bien probando a encontrar un paquete equivalente que haya sido compilado con su distribución.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s