2.6.2.- Soluciones para los problemas de dependencia de paquetes.

Cuando surge una dependencia de paquetes no satisfecha o un conflicto, ¿que se puede hacer? Hay varios métodos de abordar estos problemas. Algunos de estos funcionan bien en unas situaciones pero no en otras, por lo que debería sopesar con detenimiento las posibilidades. Entre las opciones se incluyen forzar la instalación, modificar el sistema para que satisfaga la dependencia, recompilar el paquete problemático a partir del código fuente y localizar otra versión del paquete problemático.

Forzar la instalación.- Uno de los métodos es ignorar el problema. Aunque suena arriesgado, es lo adecuado en algunos casos en los que fallan las dependencias de RPM o Debian. Por ejemplo, si la dependencia aparece en un paquete que instaló compilando el código fuente usted mismo,  puede ignorar la dependencia sin problemas. Al utilizar rpm, puede decirle al programa que ignore las dependencias que fallen utilizando el parámetro --nodeps:

Puede hacer que la instalación ignore algunos otros errores, como los conflictos con los paquetes existentes, utilizando el parámetro --force:

Advertencia: No utilice --nodeps o --force como algo natural. Ignorar las dependencias pueden meterle en problemas, por lo que debe emplear estas opciones sólo cuando sea necesario. En caso de conflicto, los mensajes de error que obtiene cuando intente instalar primero sin --force la indicarán qué ficheros de paquetes va a reemplazar, por lo que debe asegurarse de hacer una copia de éstos o de tener el paquete listo para su reinstalación si hay problemas.

Línea
Si utiliza dpkg, puede emplear los parámetros --ignore-depends=paquete, --force-depends y --force-conflicts para resolver los problemas de dependencias y conflictos en los sistemas de tipo Debian. Como hay menos diferencias entre los nombres de paquetes y los requisitos en los sistemas de tipo Debian, estas opciones suelen necesitarse con menos frecuencia en dichos sistemas.

Actualizar o reemplazar el paquete del que se depende.- Oficialmente, el modo adecuado de resolver un problema de dependencias es instalar, actualizar o reemplazar el paquete del que se depende. Supongamos que un programa necesita Qt 3.3 o superior,  entonces debería actualizar una versión anterior (como la 3.2) a la 3.3. Para realizar tal actualización, necesitará seguir el rastro e instalar el paquete apropiado. Esto no suele ser tan difícil si el nuevo paquete deseado viene de una distribución Linux y, en especial, si emplea un meta-empaquetador como Yum o APT; el paquete apropiado del que se depende debería venir con la misma distribución.

Un problema de éste método es que, a veces, los paquetes destinados para distribuciones diferentes tienen requisitos diferentes. Si ejecuta la distribución A e instala un paquete que se compiló para la distribución B, el paquete expresará sus dependencias en términos de los ficheros y versiones de la distribución B. Puede que las versiones apropiadas no estén disponibles en una forma destinada a la distribución A y, al instalar las versiones de la distribución B, a veces, se pueden provocar conflictos con otros paquetes de la distribución A. Incluso si instala el paquete actualizado y éste funciona, puede que se meta en problemas en el futuro  cuando llegue el momento de instalar algún otro programa o actualizar la totalidad de la distribución; puede que el instalador de actualización no reconozca el paquete de la distribución B o puede que no sea capaz de actualizarlo con la versión más reciente.

Recompilar el paquete problemático.- Algunas dependencias surgen a raíz de las bibliotecas y otras utilidades de soporte instaladas en el ordenador que compiló el paquete y no de los requisitos del código fuente subyacente. Si el software se recompila en un sistema que tiene paquetes diferentes, las dependencias cambiarán. Por tanto, recompilar un paquete partiendo del código fuente puede resolver, al menos, algunas dependencias.

Si utiliza un sistema de tipo RPM, el comando para recompilar un paquete es intuitivo: puede llamar a rpmbuild (o rpm con las antiguas versiones de RPM) con el nombre del paquete fuente y emplear --rebuild, como se indica:

Obviamente, para ello debe disponer del RPM fuente del paquete. Esto se consigue, normalmente, en el mismo sitio que el RPM binario. Cuando se ejecuta este comando, rpmbuild extrae el código fuente y ejecuta los comandos que hagan falta para compilar un nuevo paquete o, en ocasiones, varios nuevos paquetes (un RPM fuente puede crear varios RPM binarios). El proceso de compilación puede llevar desde unos cuantos segundos a varias horas, dependiendo del tamaño del paquete y la velocidad de su ordenador.

El resultado debería ser uno o más RPM binarios en /usr/src/nombredist/RPMS/arq, donde nombredist es el nombre de una distribución específica (como redhat en RedHat o packages en SuSE) y arq es la arquitectura de su CPU (como i386,  i586 o i686 para x86 o ppc para PowerPC). Puede pasar estos RPM a cualquier ubicación que le venga bien e instalarlos como haría con otros.

NOTA: Los paquetes fuente se encuentran también disponibles para los sistemas Debian pero, aparte de los sitios dedicados a Debian y las distribuciones relacionadas, los paquetes fuente de Debian son inusuales. Los sitios que tienen estos paquetes los proporcionan en formas que suelen ser fáciles de instalar en los sistemas Debian o similares apropiados. Por este motivo, es menos probable que se recompile un paquete Debian desde la fuente.

Localizar otra versión del paquete problemático.- Con frecuencia, el modo más sencillo de corregir un problema de dependencia o conflicto es utilizar una versión diferente del paquete que desea instalar. Podría tratarse de una versión más reciente o más antigua que la oficial (4.2.3 en lugar de 4.4.7, por ejemplo) o podría ser la misma versión oficial pero compilada para su distribución en lugar de para otra. Sitios como RPM Find (www.rpmfind.net) y el listado de paquetes Debian (www.debian.org/distrib/packages) pueden ser muy útiles para seguir la pista de las versiones alternativas de un paquete. El sitio Web o FTP de su propia distribución puede ser también un buen lugar para localizar paquetes.

Truco: Si el paquete que intenta instalar requiere bibliotecas más recientes que las que posee y no desea actualizar éstas, puede que una versión más antigua de éste sirva para las bibliotecas que tiene. Pero antes de hacer esto, debería cercionarse de que la versión más reciente del programa no corrige los fallos de seguridad. Si lo hace, debería encontrar otro modo de instalar el paquete.

El principal problema de la localización de otra versión del paquete es que, a veces, lo que necesita realmente es la versión que no se ha instalado correctamente, porque posee características que se necesitan o porque corrige errores importantes. Puede que, en ocasiones, no haya otras versiones disponibles o puede que no consiga localizar otra versión del paquete en su formato preferido.

Problemas de los scripts de inicio.- Un problema particularmente común al intentar instalar servidores de una distribución en otra es hacer que funcionen los scripts de inicio SysV. Aunque las principales distribuciones utilizan scripts de inicio SysV, estos scripts no siempre se pueden transportar de unas a otras. Las distintas distribuciones con frecuencia, implementan rutinas de soporte de maneras únicas, por lo que puede que estos scripts sean incompatibles. El resultado de esto es que el servidor instalado no se inicia a pesar de que los enlaces a los scripts de inicio son correctos. Las posibles soluciones incluyen la modificación del script de inicio que viene con el servidor, compilar un nuevo script a partir de otro de su distribución e iniciar el servidor mediante un script de inicio local como /etc/rc.d/rc.local o /etc/rc.d/boot.local. Más adelante describiremos los scripts con detalle.

NOTA: Los problemas de los scripts de inicio afectan sólo a los servidores y a otros programas que  se inician automáticamente cuando se inicia el ordenador; no afectan a las aplicaciones habituales de los usuarios o a las bibliotecas.