Cómo listar dependencias de un paquete en Linux y no romper el sistema

Si llevas un tiempo usando GNU/Linux, seguro que alguna vez te has preguntado por qué, al instalar un programa, el gestor de paquetes empieza a descargar un montón de cosas «extra». Esas librerías y paquetes adicionales son las famosas dependencias, y entenderlas marca la diferencia entre administrar tu sistema con tranquilidad o ir a ciegas rezando para no romper nada.

Además, es muy común ver tutoriales o vídeos donde alguien instala una aplicación y, como por arte de magia, añade tres o cuatro paquetes más sin explicar el motivo. Eso genera desconfianza: ¿de verdad hacen falta? ¿el sistema no debería resolverlo solo? En este artículo vamos a atacar precisamente ese problema: verás cómo listar las dependencias de un paquete en Linux (DEB, RPM, Pacman, Zypper…) y también cómo comprobar qué paquetes dependen de otro, cómo inspeccionar binarios, y qué hacer cuando las dependencias se rompen.

Qué es una dependencia y por qué es tan importante en Linux

En términos sencillos, una dependencia es un paquete (programa o biblioteca) que otro necesita para funcionar correctamente. Si instalas LibreOffice, por ejemplo, no se baja un único paquete: el «meta-paquete» principal arrastra decenas de librerías gráficas, de fuentes, de integración con el sistema, etc.

Cuando un paquete indica que necesita otros, el gestor de paquetes se encarga automáticamente de resolver esa cadena de dependencias y predependencias. Es decir, descarga e instala todo lo necesario, incluyendo las dependencias de las dependencias, y así sucesivamente hasta cerrar el árbol.

El problema aparece cuando alguna de esas condiciones no se cumple: si una librería requerida ya no existe en los repositorios, si instalas algo desde un origen externo mal empaquetado o si se interrumpe una instalación o actualización en mitad del proceso. Ahí es cuando aparecen los temidos mensajes de «dependencias incumplidas» y «paquetes rotos».

Un paquete se considera roto cuando su estado de instalación ha quedado a medias o en conflicto con el resto del sistema (por ejemplo, desempaquetado pero no configurado, o con dependencias imposibles de satisfacer). A partir de ese punto puedes encontrar errores al instalar, actualizar o eliminar otros paquetes, porque todo el sistema de dependencias queda inestable.

Por eso es clave saber cómo inspeccionar qué depende de qué, y cómo reparar cuando algo se tuerce. Veremos primero los casos más habituales en sistemas basados en Debian/Ubuntu (DEB), luego en el mundo RPM (Fedora, CentOS, RHEL, openSUSE), y finalmente otras familias como Arch Linux.

Listar dependencias en sistemas DEB (Debian, Ubuntu y derivadas)

En el ecosistema Debian y Ubuntu, contar dependencias es muy sencillo porque la pila de herramientas está muy unificada: apt, apt-cache, dpkg y utilidades complementarias como apt-rdepends cubren prácticamente todos los casos que necesitas en el día a día.

Listar dependencias de un paquete disponible en repositorios con apt-cache

Si el paquete está en los repositorios configurados, puedes ver qué necesita con:

apt-cache depends nombre_paquete

Por ejemplo, para ver de qué depende vim:

apt-cache depends vim

La salida mostrará líneas del tipo «Depends:», «PreDepends:», «Suggests:», etc., donde puedes identificar de un vistazo las dependencias obligatorias y las recomendadas. Es una forma rápida de entender qué se va a arrastrar al instalar un determinado programa.

Si quieres un nivel de detalle mayor, puedes combinarlo con otros subcomandos de apt-cache como showpkg, que además muestra dependencias inversas y versiones:

apt-cache showpkg vsftpd

Con este comando, además de los paquetes de los que depende vsftpd, verás qué otros paquetes dependen de vsftpd, información muy útil antes de desinstalar un servicio en un servidor en producción.

Ver el árbol completo de dependencias con apt-rdepends

Cuando necesitas no solo una lista plana, sino la cadena recursiva de dependencias (las dependencias de las dependencias, y así en profundidad), la utilidad estrella es apt-rdepends:

apt-rdepends nombre_paquete

Esta herramienta no suele venir instalada por defecto, así que antes tendrás que añadirla con:

sudo apt-get install apt-rdepends

Una vez instalada, apt-rdepends permite recorridos bastante potentes. Algunas opciones útiles son:

• -b (-build): muestra las dependencias directas necesarias para compilar el paquete.
• -p (-print-state): incluye el estado y versión del paquete en la salida.
• -f (-follow=DEPENDS): sigue dependencias y predependencias, generando un árbol más exhaustivo.

Si en algún momento te pierdes con la sintaxis, siempre puedes revisar el manual de la herramienta con:

man apt-rdepends

Instalar automáticamente dependencias de compilación con apt-get build-dep

En entornos de desarrollo es muy habitual necesitar todas las dependencias necesarias para compilar un paquete desde su código fuente. Para eso existe el comando:

sudo apt-get build-dep nombre_paquete

Este subcomando busca en los repositorios la información del paquete fuente y instala todos los paquetes de los que depende su proceso de compilación, pero ojo: no instala el programa en sí, solo las dependencias de construcción.

Por ejemplo, al ejecutar:

sudo apt-get build-dep gmc

el sistema mostrará un resumen del tipo «The following NEW packages will be installed…», listando todas las librerías de desarrollo que va a añadir (-dev, herramientas de compilación, etc.). Después podrás traer el código con:

apt-get source nombre_paquete

y compilar con las herramientas habituales. Es una forma bastante limpia de preparar el entorno sin tener que ir cazando dependencias a mano.

Listar dependencias de paquetes DEB sueltos (.deb descargados)

Cuando lo que tienes es un archivo .deb descargado a mano (por ejemplo, desde la web de un tercero) y quieres inspeccionar sus dependencias antes de instalarlo, puedes usar la herramienta de bajo nivel dpkg-deb:

dpkg-deb -I mipaquete.deb

Este comando mostrará la cabecera del paquete, incluyendo el campo «Depends:», donde verás claramente qué otros paquetes debe tener instalados el sistema para que ese .deb funcione correctamente. También es útil si trabajas con paquetes alternativos como AppImage, porque te ayuda a comparar qué dependencias gestionará el sistema y cuáles aporta el propio paquete.

Es especialmente útil en entornos donde no quieres romper el gestor de paquetes mezclando paquetes externos sin revisar qué arrastran o si son compatibles con la versión de tu distribución.

Otros comandos útiles en DEB: apt, dpkg, dpkg-query, which, whereis y locate

Además de listar dependencias, conviene dominar algunos comandos de consulta para saber si un paquete está instalado y dónde está. Esto te ayuda a comprobar si las dependencias están realmente satisfechas en tu sistema.

• apt -qq list nombre_paquete: muestra si un paquete está instalado, junto con versión y arquitectura.
• apt-cache policy nombre_paquete: enseña versión instalada, versión candidata y repositorio de origen.
• dpkg -l | grep -i nombre_paquete o dpkg-query –list | grep -i nombre_paquete: listan el paquete, su estado y descripción desde la base de datos de dpkg.
• which binario: si el ejecutable está en el PATH del usuario, devuelve su ruta (por ejemplo, /bin/nano).
• whereis binario: muestra no solo el ejecutable, sino también documentación y archivos relacionados (manpages, info, etc.).
• locate patrón: busca archivos en la base de datos de localización, muy rápido, aunque exige tener localizado instalado y actualizado.

Combinando estas herramientas con apt-cache y apt-rdepends puedes construir un mapa bastante completo de qué está instalado, qué lo usa y qué falta para que todo encaje.

Listar dependencias y dependencias inversas en el mundo RPM (Fedora, RHEL, CentOS, openSUSE)

En las distribuciones basadas en RPM disponemos de varias herramientas potentes. La base es rpm, que trabaja directamente con la base de datos de paquetes, y encima de ella se apoyan gestores de alto nivel como yum (en sistemas clásicos) o dnf (en versiones más modernas de Fedora y derivados).

Consultar dependencias de un paquete RPM instalado o en repositorio

Para preguntar a rpm por las dependencias de un paquete instalado, el comando típico es:

rpm -qR nombre_paquete

La opción -qR (-requires) indica a rpm que liste todos los paquetes y capacidades de las que depende ese paquete. Es equivalente, a bajo nivel, a lo que apt-cache depends hace en el mundo DEB.

Si lo que tienes es un archivo .rpm suelto (no instalado) y quieres examinar sus dependencias antes de meterlo en el sistema, el comando cambia ligeramente:

rpm -qpR archivo.rpm

Aquí la -p le dice a rpm que trabaje sobre un archivo de paquete en disco en lugar de sobre la base de datos de paquetes instalados.

Además de -R, rpm acepta combinaciones muy útiles para obtener más contexto: por ejemplo, -ql lista los archivos que contiene el paquete, -qi ofrece información detallada (resumen, versión, grupo, etc.) y -V verifica su integridad respecto a la base de datos (propietarios, permisos, hashes…).

Listar dependencias, dependencias inversas y más con Yum/DNF

Sobre la capa rpm, gestores como yum o dnf simplifican bastante la consulta y resolución de dependencias, además de gestionar repositorios, actualizaciones y todo el ciclo de vida del software.

En el caso de yum, dispones de varios subcomandos muy útiles relacionados directamente con dependencias:

• yum deplist nombre_paquete: muestra las dependencias de un paquete concreto, ya esté instalado o disponible en repositorios.
• yum resolvedep dependencia: devuelve los paquetes que satisfacen una determinada dependencia (nombre de librería, capacidad virtual, etc.).
• yum provides ruta_o_archivo: te indica a qué paquete pertenece un archivo concreto, muy útil cuando sabes qué binario o librería falta, pero no qué paquete la contiene.

Además, con yum info nombre_paquete puedes ver información amplia del paquete (incluyendo resumen y repositorio de origen) y con yum list nombre_paquete comparas la versión instalada con la disponible para actualizar.

En escenarios más avanzados, yum also integra una guía rápida de acciones como instalar, actualizar, borrar, listar grupos de paquetes, ver repositorios activos, gestionar historial de transacciones y mucho más, lo que te permite no solo consultar dependencias sino entender qué se instaló, cuándo y desde dónde.

Similitudes entre comandos RPM y Yum

Si te mueves entre rpm y yum, viene bien tener presentes algunas equivalencias básicas para no perderte:

• Instalar paquete: rpm -ivh o rpm -Uvh ≈ yum install (este último resuelve e instala dependencias).
• Eliminar paquete: rpm -e ≈ yum remove.
• Consultar información de un paquete: rpm -qi ≈ yum info.
• Buscar un paquete por nombre: yum search cadena ≈ rpm -qa | grep cadena (este último te indica si está instalado).

La moraleja es que, para consultas de dependencias, rpm te da el detalle «crudo» y yum te facilita el trabajo de resolución, descargas y operaciones masivas sobre paquetes desde repositorios remotos.

Listar dependencias en Arch Linux y derivados (Pacman / Pactree)

En Arch Linux y distribuciones basadas en Pacman (Manjaro, EndeavourOS, etc.) tienes una herramienta muy potente y cómoda para visualizar relaciones: pactree. A diferencia de las salidas planas de otros sistemas, pactree representa un árbol jerárquico de dependencias, mucho más legible a simple vista.

Por ejemplo, para inspeccionar el árbol de dependencias de vim, puedes ejecutar:

pactree vim

La salida se muestra con un estilo similar al del comando tree, ramificando cada dependencia y sus subdependencias:

vim
├─vim-runtime
├─gpm
│ └─bash
│ ├─readline
│ │ ├─glibc
│ │ ├─linux-api-headers
│ │ ├─tzdata
│ │ └─filesystem
└─acl
└─attr
└─glibc

Como ves, es muy sencillo seguir visualmente qué paquetes cuelgan de cada nivel. Si quieres invertir la perspectiva y ver qué paquetes dependen de uno concreto, también puedes usar otras herramientas de pacman, pero para la vista «hacia abajo» pactree es difícilmente superable.

Si te interesa sacarle todo el jugo, consulta las páginas de manual con:

man pactree

Listar dependencias en SUSE y openSUSE (Zypper)

En distribuciones como openSUSE y SLE, el gestor de paquetes de referencia es zypper. Además de instalar, actualizar y eliminar software, permite consultar dependencias de forma bastante cómoda.

Para ver qué requiere un paquete determinado, por ejemplo vim, puedes usar:

zypper info –requires vim

Este comando mostrará la información habitual del paquete (nombre, versión, repositorio, etc.), junto con una sección de requisitos donde se listan todas las dependencias que deben estar presentes en el sistema. Es el equivalente a los «Depends» de apt-cache o a los «Requires» de rpm -qR.

Combinado con otras opciones de zypper (como búsqueda por patrón, listado de repositorios, etc.) te permite mantener un control bastante fino de qué paquetes arrastran qué librerías dentro del entorno SUSE.

Cómo ver qué paquetes dependen de otro (dependencias reversas)

Tan importante como saber de qué depende un paquete es conocer qué otros paquetes dependen de él. Esta consulta de dependencias inversas es clave antes de desinstalar algo aparentemente «inofensivo» que, en realidad, podría usarse en medio sistema.

En sistemas Debian/Ubuntu, puedes utilizar:

• apt-cache rdepends nombre_paquete: muestra la lista de paquetes que dependen del paquete indicado.
• apt-cache showpkg nombre_paquete: además de información del paquete y sus dependencias, incluye un apartado «Reverse Depends» con los paquetes que lo requieren.

En el mundo RPM, yum también ofrece formas de verlo:

• yum deplist nombre_paquete: con la salida puedes ver, de forma indirecta, quién aporta cada dependencia.
• yum provides archivo_o_capacidad: te indica qué paquetes proporcionan una determinada librería o archivo, de modo que puedes inferir qué se vería afectado si la quitas.

Combinando estas consultas, es sencillo responder a preguntas del estilo: «si elimino esta librería, ¿qué aplicaciones dejarán de funcionar?». Y eso, en un servidor o en un entorno de escritorio crítico, es oro puro.

Inspeccionar dependencias de archivos binarios con ldd

Más allá de los gestores de paquetes, a veces te interesa averiguar qué librerías dinámicas utiliza un binario concreto, por ejemplo para depurar un error de carga o un problema con versiones de libc.

La herramienta estándar para esto en sistemas tipo Unix es ldd. Su uso básico es muy sencillo:

ldd /ruta/al/archivo_binario

La salida mostrará cada librería compartida que el binario necesita, junto con la ruta desde la que se está resolviendo y la dirección de carga. Si alguna aparece como «not found», ya sabes que falta una dependencia en el sistema o no está en una ruta de búsqueda válida.

Si quieres ver la información con más detalle y seguir las dependencias internas de las propias librerías, puedes emplear:

ldd -v /ruta/al/archivo_binario

La opción -v añade información extra y puede ayudarte a verificar versiones, símbolos exportados y otros detalles finos que, en entornos de producción, muchas veces marcan la diferencia entre que un servicio arranque o se estrelle silenciosamente.

Reparar paquetes rotos y dependencias incumplidas en sistemas Debian/Ubuntu

Por muy cuidadoso que seas, tarde o temprano te encontrarás con un sistema que se queja de paquetes rotos, dependencias incumplidas o archivos de bloqueo (lock files). Antes de entrar en pánico, es importante entender el concepto y seguir un orden de recuperación razonable.

Un paquete roto suele aparecer cuando se interrumpe una instalación o actualización, cuando se instalan paquetes externos mal construidos o cuando se mezclan repositorios incompatibles. El síntoma típico: no puedes instalar ni actualizar nada porque apt se niega a continuar hasta que se resuelva el conflicto.

Primer intento: dpkg y apt para reconfigurar y reparar

El primer paso lógico es pedir a dpkg que termine de configurar lo que quedó a medias:

sudo dpkg –configure -a

Este comando fuerza la configuración de todos los paquetes desempaquetados pero no configurados. Si había scripts de postinstalación pendientes, se ejecutarán ahora. Muchas veces, solo con esto se resuelven estados incoherentes».

Si sigue sin funcionar, conviene limpiar la caché local de .deb para evitar residuos corruptos y liberar espacio en disco:

sudo apt-get clean && sudo apt-get autoclean

Después, regeneramos la información de repositorios y dejamos que apt intente recomponer dependencias con la opción de corrección:

sudo apt-get update –fix-missing
sudo apt-get install -f

La combinación de –fix-missing y -f (-fix-broken) indica a apt que intente resolver paquetes inconsistentes y dependencias insatisfechas, instalando o corrigiendo lo que haga falta. Es uno de los recursos más efectivos antes de pasar a medidas más agresivas.

Si aún aparece un mensaje de bloqueo del tipo «Could not get lock», puede que haya archivos de bloqueo obsoletos. En ese caso, y solo si estás seguro de que no hay un apt o dpkg real ejecutándose, puedes eliminarlos:

sudo rm /var/lib/apt/lists/lock && sudo rm /var/cache/apt/archives/lock && sudo rm /var/lib/dpkg/lock

Tras esto, repite la secuencia de comandos anterior (configure, clean, update, install -f) para comprobar si el sistema vuelve a un estado sano.

Eliminar manualmente el paquete roto con dpkg

Si el problema persiste, lo siguiente es identificar exactamente qué paquete está en estado roto. Para ello puedes usar:

sudo dpkg -l | grep ^..r

Los paquetes que aparecen con una «r» en su estado indican instalaciones incompletas o rotas. Una vez identificado el nombre, puedes intentar eliminarlo de forma forzada:

sudo dpkg –remove –force-remove-reinstreq nombre_paquete

Este comando obliga a dpkg a sacar de en medio ese paquete conflictivo, incluso si su estado no es coherente. Tras esto, de nuevo, limpia la caché y actualiza:

sudo apt-get clean && sudo apt-get autoclean
sudo apt-get update && sudo apt-get dist-upgrade

Si el sistema se actualiza sin quejas, lo más probable es que hayas devuelto la base de datos de paquetes a un estado estable y puedas continuar trabajando con normalidad.

Usar Synaptic para arreglar paquetes rotos de forma gráfica

Si prefieres una aproximación más visual o estás ayudando a alguien menos cómodo en la terminal, el gestor de paquetes Synaptic sigue siendo una herramienta muy potente.

Primero instálalo (si no lo tienes):

sudo apt-get install synaptic

Después, ábrelo y:

1. Activa los Filtros y selecciona el filtro de Rotos.
2. Localiza el paquete que aparece como dañado.
3. Haz clic derecho sobre él y elige «Marcar para desinstalar completamente».
4. Aplica los cambios para que Synaptic intente eliminar el paquete problemático y recomponer las dependencias.

Además, en el menú Editar → Reparar paquetes rotos, Synaptic incluye una opción automática que intenta resolver inconsistencias en lote, lo que puede ahorrarte varios pasos manuales.

Último recurso: editar el fichero de estado de dpkg

Si todo lo anterior falla, queda una opción avanzada y delicada: editar directamente el fichero /var/lib/dpkg/status, que es donde dpkg almacena el estado de cada paquete instalado.

La idea es abrirlo con un editor de texto en modo superusuario:

sudo nano /var/lib/dpkg/status

Una vez dentro, busca el bloque que describe el paquete roto (empieza por «Package: nombre_paquete» e incluye varios campos como «Status:», «Version:», etc.) y elimina todo ese bloque. Es como borrar su existencia de la base de datos de dpkg.

Guarda los cambios, cierra el editor y, a continuación, ejecuta:

sudo apt-get clean && sudo apt-get update && sudo apt-get dist-upgrade

Si no hay más inconsistencias, el sistema debería quedar en estado funcional. Esta técnica conviene usarla con cuidado y, si es posible, acompañada de una copia de seguridad del fichero status por si necesitas revertir el cambio.

Con todo este arsenal de comandos —apt-cache, apt-rdepends, rpm, yum, pactree, zypper, ldd y las herramientas de reparación de dpkg y apt— ya tienes una visión bastante completa de cómo listar dependencias de un paquete en Linux, saber qué depende de qué y cómo actuar cuando algo se rompe. Dominar estas herramientas no solo te da tranquilidad al instalar software, sino que te convierte en alguien capaz de leer lo que el sistema te está diciendo en cada error y tomar decisiones informadas sin ir a ciegas.