2.6.1.- Problemas de dependencia reales e imaginarios.

Las dependencias y los conflictos pueden aparecer por varias razones, entre las que incluyen:

• Bibliotecas o programas de soporte que fallan.- Uno de los problemas de dependencia más comunes se debe a que falta un paquete de soporte. Por ejemplo, todos los programas de KDE se basan en Qt, un conjunto de widgets que proporciona herramientas GUI variadas. Si no está instalado Qt, no podrá instalar ningún paquete KDE que utilice paquetes RPM o Debian. Las bibliotecas (código de  soporte que puede ser utilizado por muchos programas diferentes como si fuera parte del propio programa) son una fuente de problemas de este tipo particularmente común.
• Bibliotecas o programas de soporte no compatible.- Aunque tenga una biblioteca o programa de soporte instalado en su sistema, su versión puede no ser correcta. Por ejemplo, si un programa requiere Qt 3.3, la presencia de Qt 2.2 no hará mucho bien. Afortunadamente, las convenciones de nomenclaturas de bibliotecas de Linux le permiten instalar varias versiones de una biblioteca por si tiene programas con requisitos contrarios.
• Ficheros o características duplicados.- Los conflictos surgen cuando un paquete incluye ficheros que ya están instalados y que pertenece a otro paquete. Habrá ocasiones en que también puedan entrar en conflicto características amplias, como la de los paquetes de servidor Web. Los conflictos de características suelen ir acompañados de conflictos de nombres. Los conflictos son más comunes cuando se mezclan paquetes destinados a distribuciones diferentes, porque las distribuciones pueden repartir los ficheros entre los paquetes de maneras diferentes.
• Diferencia en los nombres.- Los sistemas de administración de paquetes de RPM y Debian asignan nombres a sus paquetes. Estos nombres no siempre coinciden de una a otra distribución. Por este motivo, si un paquete busca a otro por el nombre, puede que el primer paquete no se instale en otra distribución, incluso aunque esté instalado el paquete apropiado, debido a que el paquete objetivo posee un nombre diferente.

Algunos de estos problemas son muy reales y muy serios. Por ejemplo, se deben instalar las bibliotecas no instaladas (aunque, a veces, hay bibliotecas que parecen faltar cuando, en realidad, no es así, como comentaremos más adelante). Otros, como los nombres de paquetes que no coinciden,  son objetos del sistema de empaquetado. Lamentablemente, no siempre es fácil saber a que categoría pertenece un conflicto. Cuando se utiliza un sistema de administración de paquetes, puede utilizar el mensaje de error devuelto por el sistema de paquetes, junto con su propia experiencia y su conocimiento de determinados paquetes, para emitir un juicio. Por ejemplo, si RPM informa de que falta un montón de bibliotecas que le resultan poco conocidas, es probable que tenga que seguir la pista de, al menos, un paquete, a no ser que haya instalado las bibliotecas de algún otro modo, en cuyo caso lo recomendable sería forzar la instalación.