dpkg es el motor que hay debajo de apt. Cuando ejecutas apt install nginx, en algún momento de ese proceso apt resuelve dependencias, descarga los .deb necesarios y luego llama a dpkg para hacer el trabajo real: desempaquetar archivos, registrarlos en la base de datos, ejecutar los scripts de instalación. dpkg no sabe nada de repositorios ni de dependencias transitivas —eso es responsabilidad de las capas superiores—, pero sí mantiene el registro canónico del estado de cada paquete en el sistema.
La base de datos que gestiona dpkg vive en /var/lib/dpkg/. El fichero status dentro de ese directorio contiene el estado de todos los paquetes conocidos por el sistema. Cuando un paquete está instalado, desinstalado pero con configuración retenida, o completamente purgado, esa información está ahí. apt consulta esa base de datos constantemente; dpkg es quien la escribe.
¿Cuándo usas dpkg directamente? Principalmente en tres situaciones: cuando tienes un .deb descargado manualmente que no está en ningún repositorio, cuando necesitas inspeccionar qué archivos pertenecen a qué paquete, o cuando necesitas reconfigurar un paquete ya instalado. Lo que rompes si lo usas mal es la coherencia de dependencias: dpkg -i instala lo que le das sin comprobar si las dependencias están satisfechas, y si no lo están, el paquete quedará en estado de error (iHalf-installed o iF) hasta que lo arregles. El sistema sigue funcionando, pero apt se quejará en cada operación hasta que resuelvas esa deuda. El arreglo estándar es apt-get install -f (donde -f significa fix broken), que lee el estado roto y resuelve las dependencias que faltan.
dpkg-reconfigure merece mención aparte. Cuando instalas un paquete que usa debconf —el sistema de configuración interactiva de Debian— para hacerte preguntas durante la instalación (zona horaria, idioma, configuración de servicios), esas respuestas quedan guardadas. Si necesitas cambiar la zona horaria seis meses después, no hace falta reinstalar tzdata: dpkg-reconfigure tzdata relanza exactamente el mismo asistente que viste durante la instalación.
# ── Escenario: instalar un .deb externo e inspeccionar el sistema ────── # 1. Instalar un .deb descargado manualmente (por ejemplo, un agente de # monitorización que el proveedor distribuye fuera de repositorios) sudo dpkg -i /tmp/datadog-agent_7.50.0-1_amd64.deb # Si falla por dependencias no satisfechas, dpkg dejará el paquete en # estado roto pero anotado. apt-get install -f lo resuelve: sudo apt-get install -f # 2. Ver todos los paquetes instalados con su estado dpkg -l # Formato de cada línea: dos letras de estado + nombre + versión + arch # Primera letra: i = instalado, u = desconocido, r = eliminado # Segunda letra: i = ok, c = sólo config, F = medio fallido, H = medio instalado # 3. Filtrar con glob — todos los paquetes cuyo nombre contenga "nginx" dpkg -l '*nginx*' # 4. Ver exactamente qué archivos instaló nginx en el sistema dpkg -L nginx # Útil cuando no recuerdas si el binario está en /usr/sbin o /usr/bin, # o dónde quedó el fichero de configuración principal # 5. El camino inverso: dado un archivo, saber qué paquete lo instaló dpkg -S /usr/sbin/nginx # Responde: nginx: /usr/sbin/nginx # También funciona con rutas parciales si hay ambigüedad # 6. Exportar la lista completa de paquetes para replicar el sistema dpkg --get-selections > /root/paquetes-$(hostname)-$(date +%F).txt # El formato es "nombre-paquete install" o "nombre-paquete deinstall" # Para restaurar en otro sistema: # dpkg --set-selections < paquetes-servidor1-2024-01-15.txt # apt-get dselect-upgrade # 7. Reconfigurar un paquete ya instalado # Cambiar la zona horaria sin reinstalar nada: sudo dpkg-reconfigure tzdata # O regenerar los locales del sistema: sudo dpkg-reconfigure locales
Qué está pasando en cada paso
El estado de dos letras que muestra dpkg -l en la columna izquierda no es decorativo. La primera letra es el estado deseado (want): i significa que el sistema quiere que esté instalado, r que quiere que esté eliminado. La segunda es el estado real (status): i significa instalado correctamente, c significa que el paquete fue eliminado pero sus ficheros de configuración siguen en disco. Cuando ves rc, el paquete no está instalado pero quedan sus configs —apt purge o dpkg --purge limpian eso—. Cuando ves iF o iH, tienes un paquete a medio instalar que necesita atención.
El glob en dpkg -l '*nginx*' va entre comillas para que sea el propio dpkg quien expanda el patrón contra su base de datos, no el shell. Si dejas que el shell lo expanda, intentará resolver el glob en el directorio actual y probablemente no encuentre nada o resuelva algo completamente diferente.
dpkg -L y dpkg -S son operaciones de consulta pura sobre la base de datos; no tocan el disco más allá de leer /var/lib/dpkg/info/. Por eso son instantáneas. dpkg -S hace una búsqueda lineal sobre todos los ficheros registrados, así que en sistemas con muchos paquetes puede tardar un segundo. Si necesitas hacer muchas búsquedas de ese tipo, dlocate o apt-file (que mantiene un índice propio) son más eficientes.
El formato de --get-selections está diseñado específicamente para ser consumido por --set-selections. No es una lista de texto genérica: dpkg la interpreta literalmente al restaurar, marcando cada paquete con el estado deseado que indica la segunda columna. La restauración con apt-get dselect-upgrade es necesaria porque --set-selections sólo actualiza la base de datos de dpkg; es apt quien descarga e instala lo que falta.
dpkg-reconfigure funciona porque los paquetes que usan debconf almacenan las respuestas del usuario en /var/cache/debconf/config.dat. Al relanzar el asistente, debconf carga esas respuestas como valores por defecto y el script de configuración (/var/lib/dpkg/info/<paquete>.config) las aplica al sistema. Cambiar la zona horaria mediante dpkg-reconfigure tzdata es exactamente lo mismo que hacerlo a mano editando /etc/localtime y /etc/timezone, salvo que el asistente gestiona ambos ficheros de forma consistente y ejecuta los ganchos necesarios.
N° 55