Debian 13 “No se puede localizar el paquete»: repositorio, arquitectura y trampas de sources.list (y soluciones)

octubre 3, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 9

¿Te fue útil?

Debian 13 “No se puede localizar el paquete”: repositorio, arquitectura y trampas de sources.list (y soluciones)

Escribes apt install, pulsas Enter y Debian responde con calma: “No se puede localizar el paquete …”. El paquete existe. Tu compañero lo instaló la semana pasada. Tu memoria muscular insiste en que debería funcionar.

Este error no es un único problema. Es una familia de malas configuraciones y suposiciones obsoletas: nombres de suite, componentes, arquitecturas, mirrors, claves, pinning y, a veces, simplemente tu propio optimismo. Vamos a cazarlo como adultos.

Guía de diagnóstico rápido (haz esto primero)

Cuando la producción espera y no tienes tiempo para un debate filosófico con APT, haz esto en orden. El objetivo es identificar si el cuello de botella es metadatos, repositorios, arquitectura o política.

1) Confirma la visión de APT del mundo (frescura de metadatos)

Ejecuta apt-get update y lee los errores, no solo el código de salida.
Si ves NO_PUBKEY, 403, 404 o problemas con el Release file, detente. Arregla eso primero.

2) Pregunta a APT si conoce el nombre del paquete

apt-cache show pkg y apt-cache policy pkg te dicen si el paquete existe en tus repos configurados.
Si APT no lo conoce, el problema es sources/componentes/suite/arch/sincronización del mirror.

3) Valida suite y componentes (la trampa más común en Debian 13)

Comprueba que tu suite coincida con la realidad (p. ej., trixie vs stable vs testing).
Asegúrate de que non-free-firmware esté presente si esperas paquetes de firmware.

4) Valida arquitectura y multiarch

Confirma con dpkg --print-architecture.
Si intentas instalar :i386 en amd64, añade la arquitectura y actualiza.

5) Revisa pinning / preferences

apt-cache policy mostrará pines y la selección de candidato.
Rara vez el pinning produce “No se puede localizar el paquete”, pero con frecuencia produce “no installation candidate” y termina mal reportado en tickets.

Si haces esos cinco pasos, normalmente tendrás al culpable en menos de diez minutos. Si no, probablemente estás en el infierno de sincronización del mirror o tratando con un repositorio que dejó de publicar para tu suite/arch.

Qué significa realmente “No se puede localizar el paquete”

APT no te está diciendo “el paquete no existe en Debian”. Te está diciendo algo más estrecho y más molesto:

El índice local de paquetes de APT no contiene ese nombre de paquete para ninguna combinación habilitada de repositorio, suite, componente y arquitectura.
O estás pidiendo un nombre de paquete que no coincide con ningún paquete en esos índices (error tipográfico, paquete renombrado, paquete de transición eliminado).

Por eso el mismo paquete puede existir en los servidores de Debian y aun así ser “inubicable” para tu host. Tu host solo conoce lo que tiene en sus índices. Los índices provienen de los repositorios configurados. Los repositorios se dividen por:

Suite (p. ej., trixie, stable, testing)
Componente (p. ej., main, contrib, non-free, non-free-firmware)
Arquitectura (p. ej., amd64, arm64, i386)

Fallas en cualquiera de estas capas y el paquete desaparece del universo de APT.

También: Debian 13 empuja a más personas hacia el “nuevo formato de sources” y hábitos de keyring más estrictos. Es buena ingeniería. También es una nueva fuente de maneras de pegarse un tiro en el pie—de forma limpia, determinista y a escala.

Hechos y contexto que explican lo raro

Hecho 1: Debian divide los repositorios en suites y componentes para separar objetivos de estabilidad y restricciones de licencia; tu configuración decide qué puede “ver” APT.
Hecho 2: Debian introdujo el componente non-free-firmware (separado de non-free) para que el firmware pueda habilitarse explícitamente sin arrastrar todo lo demás.
Hecho 3: Multiarch en Debian permite instalar paquetes de arquitecturas foráneas (como :i386 en amd64), pero APT no descargará esos índices a menos que añadas la arquitectura.
Hecho 4: Los mensajes de error de APT son precisos pero no siempre amigables: “No se puede localizar el paquete” trata sobre entradas de índice faltantes, no sobre accesibilidad de red o DNS (esos normalmente aparecen durante apt update).
Hecho 5: Los metadatos del repositorio de Debian están firmados; las configuraciones modernas prefieren keyrings por repositorio con signed-by= en vez de volcar claves en un cubo de confianza global.
Hecho 6: Los mirrors pueden estar temporalmente fuera de sincronía; durante transiciones puedes ver paquetes faltantes en un mirror y presentes en otro.
Hecho 7: Debian soporta tanto sources.list como archivos .sources estilo deb822; mezclarlos casualmente puede producir duplicados, suites en conflicto o comportamiento de pin sorprendente.
Hecho 8: Los paquetes se renombran, dividen o eliminan entre lanzamientos; el nombre que recuerdas de un Debian anterior puede ser ahora un paquete de transición o haber desaparecido por completo.

Una cita que vale la pena mantener pegada al monitor:

“La esperanza no es una estrategia.” — Gene Kranz (idea parafraseada)

Tareas prácticas: comandos, salidas, decisiones (12+)

Estos son los chequeos que ejecuto en servidores reales. Cada tarea incluye: comando, un fragmento realista de salida, qué significa la salida y la decisión que tomas a continuación.

Task 1: Confirma tu versión de Debian y el nombre en clave (no adivines)

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Significado: Estás en trixie. Si tu lista de fuentes apunta a bookworm o a stable en un entorno con pinning, espera sorpresas.

Decisión: Alinea las fuentes a trixie (o elige conscientemente stable/testing con un pin que puedas explicar a tu yo futuro).

Task 2: Ejecuta update y léelo realmente

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://security.debian.org/debian-security trixie-security InRelease
Get:3 http://deb.debian.org/debian trixie-updates InRelease [55.4 kB]
Reading package lists... Done

Significado: Se obtuvieron los índices correctamente. Si aún no puedes localizar un paquete, probablemente sea suite/componente/arch/nombre—no conectividad.

Decisión: Pasa a tareas de descubrimiento de paquetes (policy/show/search) en lugar de depurar DNS.

Task 3: Detecta problemas de firma/clave temprano

cr0x@server:~$ sudo apt-get update
Get:1 https://repo.vendor.example/debian trixie InRelease [3,214 B]
Err:1 https://repo.vendor.example/debian trixie InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
Reading package lists... Done
W: GPG error: https://repo.vendor.example/debian trixie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
E: The repository 'https://repo.vendor.example/debian trixie InRelease' is not signed.

Significado: APT se niega a confiar en el repo; los paquetes de él son efectivamente invisibles.

Decisión: Instala la clave del proveedor en un keyring dedicado y referenciála con signed-by= en la entrada del origen (no uses el volcado global de claves obsoleto).

Task 4: Imprime las fuentes configuradas (ambos formatos)

cr0x@server:~$ grep -R --no-filename -nE '^(deb|Types:)' /etc/apt/sources.list /etc/apt/sources.list.d/* 2>/dev/null
1:deb http://deb.debian.org/debian trixie main
2:deb http://deb.debian.org/debian trixie-updates main
3:deb http://security.debian.org/debian-security trixie-security main
/etc/apt/sources.list.d/vendor.sources:1:Types: deb

Significado: Tienes entradas clásicas en sources.list y al menos un archivo .sources deb822.

Decisión: Inspecciona también los archivos deb822; muchos incidentes de “paquete no encontrado” son simplemente “suite equivocada en el otro archivo que olvidaste que existía”.

Task 5: Inspecciona un archivo de origen deb822 por errores de suite/componente

cr0x@server:~$ sed -n '1,120p' /etc/apt/sources.list.d/vendor.sources
Types: deb
URIs: https://repo.vendor.example/debian
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/vendor-archive-keyring.gpg

Significado: Ese repo está fijado a stable. En Debian 13 eso puede estar bien, o puede ser incompatible con paquetes del proveedor que publican solo para nombres en clave específicos.

Decisión: Si la documentación del proveedor espera trixie, cambia la suite. Si solo publican para bookworm, detente y reevalúa—mezclar es un riesgo que debes justificar.

Task 6: Verifica que APT conozca el nombre del paquete

cr0x@server:~$ apt-cache show zfsutils-linux
N: Can't select versions from package 'zfsutils-linux' as it is purely virtual

Significado: El nombre existe pero es virtual; puede que necesites un paquete proveedor, o que el nombre del paquete haya cambiado en tu suite.

Decisión: Usa apt-cache showpkg o apt-cache policy para identificar proveedores; no sigas intentando apt install como si fuera una máquina tragamonedas.

Task 7: Comprueba versiones candidatas y orígenes de repo

cr0x@server:~$ apt-cache policy openssl
openssl:
  Installed: 3.3.1-1
  Candidate: 3.3.1-1
  Version table:
 *** 3.3.1-1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status

Significado: APT ve el paquete, ve su origen y tiene un candidato. Así es como luce “saludable”.

Decisión: Si tu paquete faltante no muestra ninguna Version table, no está en los índices habilitados. Ve a arreglar sources/componentes/arch.

Task 8: Usa apt-cache search para detectar paquetes renombrados

cr0x@server:~$ apt-cache search --names-only '^python3-venv$'
python3-venv - venv module for python3 (default python3 version)

Significado: El paquete exacto existe. Si la instalación aún falla, estás ante otro problema (quizá pinning o paquetes retenidos).

Decisión: Instálalo; si falla con “no installation candidate”, ve a las tareas de pinning y preferences.

Task 9: Confirma la arquitectura del sistema (y deja de instalar lo incorrecto)

cr0x@server:~$ dpkg --print-architecture
amd64

Significado: La arquitectura nativa es amd64.

Decisión: Si intentas instalar paquetes :i386 (común para herramientas legacy), añádelos correctamente.

Task 10: Comprueba arquitecturas foráneas habilitadas (multiarch)

cr0x@server:~$ dpkg --print-foreign-architectures

Significado: Ninguna habilitada.

Decisión: Si el paquete que deseas existe solo como i386, habilítalo.

Task 11: Habilita i386 multiarch correctamente

cr0x@server:~$ sudo dpkg --add-architecture i386
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie/main i386 Packages [9,112 kB]
Fetched 9,112 kB in 2s (4,230 kB/s)
Reading package lists... Done

Significado: APT ahora descarga índices i386.

Decisión: Reintenta apt install pkg:i386. Si sigue faltando, no está publicado para i386 en esa suite.

Task 12: Confirma que los componentes incluyen lo que necesitas (non-free-firmware es un fallo frecuente)

cr0x@server:~$ grep -n '^deb ' /etc/apt/sources.list
1:deb http://deb.debian.org/debian trixie main
2:deb http://security.debian.org/debian-security trixie-security main

Significado: Solo main está habilitado. Los paquetes de firmware en non-free-firmware serán invisibles.

Decisión: Añade non-free-firmware (y non-free/contrib solo si hay una razón explícita).

Task 13: Actualiza fuentes para incluir non-free-firmware

cr0x@server:~$ sudo sed -i 's/ main$/ main non-free-firmware/' /etc/apt/sources.list
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages [32.1 kB]
Fetched 32.1 kB in 1s (35.7 kB/s)
Reading package lists... Done

Significado: Ahora estás indexando ese componente.

Decisión: Reintenta la instalación del firmware; si funciona, documenta por qué se habilitó non-free-firmware (para que la próxima auditoría no lo trate como accidental).

Task 14: Detecta entradas duplicadas/contradictorias (colisión clásico + deb822)

cr0x@server:~$ apt-get -o Debug::pkgAcquire::Auth=true update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian stable InRelease
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:1 and /etc/apt/sources.list.d/debian.sources:1
Reading package lists... Done

Significado: Estás indexando dos suites (trixie y stable) y duplicando objetivos. Eso no es “redundancia.” Eso es “incidente futuro”.

Decisión: Elige un enfoque. Prefiere un solo archivo deb822 para los repos oficiales de Debian en sistemas más nuevos, o mantén un archivo clásico limpio—solo no uses ambos a medias.

Task 15: Valida que un paquete exista en tus componentes habilitados

cr0x@server:~$ apt-cache policy firmware-iwlwifi
firmware-iwlwifi:
  Installed: (none)
  Candidate: 20240811-1
  Version table:
     20240811-1 500
        500 http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages

Significado: El paquete de firmware está presente y proviene del componente esperado.

Decisión: Instálalo. Si falta, o no tienes el componente o estás usando una suite donde se llama de otra forma.

Task 16: Prueba que un problema de red/proxy está corrompiendo la vista de APT

cr0x@server:~$ sudo apt-get update
Ign:1 http://deb.debian.org/debian trixie InRelease
Err:1 http://deb.debian.org/debian trixie InRelease
  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/trixie/InRelease  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.

Significado: Estás trabajando con índices obsoletos. “No se puede localizar el paquete” puede ser simplemente porque tus listas de paquetes son antiguas o incompletas.

Decisión: Arregla conectividad/proxy/firewall. Hasta que el update esté limpio, trata la disponibilidad de paquetes como poco fiable.

Broma 1: APT no “pierde” paquetes. Solo te hace gaslighting hasta que recuerdas que cambiaste el mirror el mes pasado.

Trampas de sources.list y deb822 en Debian 13

Las instalaciones de Debian 13 a menudo contienen una mezcla de viejo /etc/apt/sources.list y archivos /etc/apt/sources.list.d/*.sources (deb822). Ambos funcionan. La trampa está cuando no concuerdan.

Confusión de suite: stable/testing vs nombres en clave

Usar stable o testing es cómodo hasta que no lo es. Cuando Debian se mueve, esas etiquetas se mueven con él. Eso está bien para escritorios. En producción, es como despertarse con una libc diferente que la de ayer.

Si tu problema es “no se puede localizar el paquete”, la confusión de suite se manifiesta así:

Estás en Debian 13 (trixie), pero tus fuentes apuntan a bookworm. Los paquetes introducidos en trixie no existirán.
Estás en Debian 13, pero un repositorio de terceros publica solo para bookworm, y por error lo configuraste en trixie. APT ve que no hay índice Packages para tu suite y pierde acceso a esos paquetes tras mostrar advertencias durante las actualizaciones.

Omisión de componente: “main” no es todo el sistema

El “main” de Debian contiene mucho. No contiene todo lo que la gente asume que es “solo cosas de Linux”. El firmware es el ejemplo clásico, especialmente en portátiles, Wi‑Fi y algunos HBAs de almacenamiento.

En Debian 13, si necesitas firmware y no tienes non-free-firmware, verás “no se puede localizar el paquete firmware-…”. Eso no es que Debian esté roto. Es que Debian es explícito.

Errores de Signed-by: el repo existe, pero no lo confías

APT moderno prefiere limitar la confianza. Bien. Pero eso significa que puedes acabar con fácilmente:

Signed-By apuntando a un archivo que no existe
un keyring instalado, pero la entrada del repo no lo referencia
una entrada de repo que referencia la clave equivocada (común con rotación de claves)

En todos estos casos, el repo puede ser alcanzable, pero los paquetes permanecen efectivamente no disponibles. APT advertirá durante apt update. Si ignoras esas advertencias, te ganas el error.

Deb822: un archivo puede definir múltiples entradas

El formato deb822 es más limpio para automatización, pero también es más fácil de esconder complejidad. Un archivo puede contener varias secciones. La gente hojea la primera y se pierde la segunda que fija otra suite o deshabilita un componente.

Trampas de arquitectura: amd64 vs i386 vs arm64

Los problemas de arquitectura son aburridos, por eso sobreviven en flotas empresariales. Puedes mirar la configuración del repo durante una hora y pasar por alto que estás en arm64.

Patrones comunes

Arquitectura de hardware equivocada: Estás en arm64 (instancias cloud, algunos portátiles), pero asumiste amd64. Algunos repositorios de terceros no publican paquetes arm64.
Multiarch no habilitado: Quieres :i386, pero nunca añadiste i386. APT no descarga índices i386. El paquete está “faltante”.
El paquete no está construido para tu arch: Los repos oficiales de Debian pueden no compilar cada paquete para todas las arquitecturas (especialmente paquetes marginales). El paquete existe, simplemente no para ti.

Cómo probarlo rápido

Mira la salida de apt-cache policy. Si ves una línea de origen como:

... trixie/main amd64 Packages entonces estás viendo metadatos amd64.
Si nunca ves tu arquitectura en las líneas del repo, te faltan metadatos (suite equivocada, repo equivocado o update fallando).

Componentes: main, contrib, non-free, non-free-firmware

En esta sección “no se puede localizar el paquete” deja de ser misterio y se convierte en papeleo.

Qué significa cada componente operativamente

main: Cumple con las Debian Free Software Guidelines. Soportado en el sentido normal de Debian. Aquí es donde quieres vivir.
contrib: Software libre que depende de cosas non-free. Es una señal de que estás por hacer un intercambio.
non-free: Software no libre. A veces necesario, a menudo lamentable, siempre digno de documentar.
non-free-firmware: Firmware no libre. Frecuentemente necesario para que el hardware funcione. Se mantiene separado para que puedas habilitarlo sin abrir completamente las compuertas de non-free.

El consejo más práctico: habilita non-free-firmware solo si lo necesitas, pero no finjas que no lo necesitas. Interfaces de red medio funcionales no te hacen moralmente superior; te hacen llegar tarde.

Problemas de mirror y red que simulan paquetes faltantes

A veces el paquete realmente falta—en tu mirror elegido, ahora mismo. Los mirrors divergen. Los proxies cachean incorrectamente. Los gateways de seguridad reescriben tráfico. Y ocasionalmente un mirror interno está sirviendo los índices del martes pasado porque su trabajo de rsync falló.

Síntomas de espejo fuera de sincronía

apt-get update tiene éxito, pero no puedes encontrar paquetes que colegas sí encuentran.
apt-cache policy muestra versiones inesperadamente antiguas en todo.
Un entorno (dev) ve paquetes, otro (prod) no, a pesar de la “misma configuración”.

Cómo manejarlo

En producción, no cambies mirrors al azar en un host. Decide si estás usando:

un mirror oficial (bueno para portátiles y flotas pequeñas), o
un mirror interno controlado (bueno para reproducibilidad), o
un proxy de caching (bueno hasta que no lo sea).

Luego monitóralo. Sí, monitorea tu cadena de suministro de paquetes como si fuera un servicio. Lo es.

Pinning y suites mixtas: el asesino silencioso de paquetes

El pinning es poderoso. También es cómo creas un sistema que solo una persona puede actualizar, y esa persona está de vacaciones.

El pinning normalmente causa “no installation candidate” o fallos del solucionador de dependencias, pero contribuye a “no se puede localizar el paquete” cuando impide que APT considere una suite donde existe el paquete—o cuando crees que habilitaste una suite pero el pinning la deja efectivamente neutralizada.

Dónde se esconde el pinning

/etc/apt/preferences
/etc/apt/preferences.d/*.pref
automatización que deja archivos ahí (scripts de construcción de imágenes, gestión de configuración)

Qué hacer

Usa apt-cache policy para entender la selección de candidatos. Luego decide si estás ejecutando:

un sistema de una sola suite (recomendado para la mayoría de servidores), o
un sistema de suites mixtas (solo si puedes explicar la historia de dependencias y tienes músculo para rollback).

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición equivocada

Un equipo de plataforma desplegó imágenes Debian 13 para una nueva tanda de gateways de almacenamiento. La pipeline de build “estandarizó” las fuentes de APT usando stable en todas partes. Esa etiqueta funcionó en CI. Incluso funcionó en staging. Todos asintieron y continuaron.

Dos semanas después, se necesitó un paquete del proveedor para exportar telemetría NVMe. El ingeniero en turno intentó instalarlo. “No se puede localizar el paquete.” Asumieron que el repo del proveedor estaba caído y lo escalaron. El soporte del proveedor respondió, con educación, que el repo estaba bien y tenía paquetes para trixie.

El giro: el repo del proveedor estaba configurado con Suites: stable, pero el proveedor no publicó bajo esa etiqueta móvil—solo bajo nombres en clave. APT pedía felizmente dists/stable, recibía un 404 y trataba al repo como inexistente después de que las advertencias aparecieran durante los updates.

El incidente no era el paquete faltante. El incidente fue el retraso en el despliegue y la carrera por reconstruir imágenes mientras los equipos de almacenamiento esperaban. La causa raíz fue “stable significa Debian stable en todas partes”, una suposición humana razonable que resultó operativamente incorrecta para repos de terceros.

La solución fue aburrida: usar nombres en clave para repos de terceros y hacer cumplir “sin advertencias en apt-get update” en CI. Esa última parte importó. Las advertencias son donde APT te dice la verdad, a su manera emocionalmente distante.

Mini-historia 2: La optimización que salió mal

Otra organización quería aprovisionamiento más rápido. Alguien añadió un proxy de caching interno frente a los mirrors de Debian. Redujo drásticamente los tiempos de instalación. Los tickets bajaron. La dirección sonrió. Luego escalaron a más regiones y más segmentación de red.

Tres meses después, una respuesta a una vulnerabilidad requirió desplegar un paquete actualizado en la flota. La mitad de los hosts dijo “No se puede localizar el paquete”, la otra mitad se actualizó bien, y nada se correlacionó limpiamente con la versión del SO. El on-call empezó a culpar a los mirrors de Debian, porque eso es lo que hace la gente ante disponibilidad inconsistente.

El verdadero problema: el proxy cacheaba metadatos de repositorio agresivamente y no respetaba correctamente los cambios de release durante una transición de mirror. Sirvió listas de paquetes obsoletas a algunos segmentos y más nuevas a otros, según el tiempo de expulsión de la caché. APT no estaba roto; le estaban mintiendo.

Lo “arreglaron” vaciando caches durante las actualizaciones, lo que ayudó una vez. Pero no resolvió el riesgo sistémico. Finalmente la solución correcta fue tratar el proxy como un servicio de producción: actualizarlo, configurar semántica de caché correcta para metadatos APT y añadir monitoreo que compare timestamps del Release esperado versus lo que reciben los clientes.

La optimización es estupenda hasta que optimizas fuera la determinismo. Las cuentas llegan más tarde, usualmente a las 2 a.m.

Mini-historia 3: La práctica aburrida que salvó el día

Una compañía financiera ejecutaba Debian en entornos regulados. Tenían una regla: cada imagen base debe incluir un único archivo deb822 controlado por versión para repos de Debian, y la build de la imagen falla si apt-get update emite advertencias o errores.

Era impopular. Los desarrolladores querían añadir repos ad hoc. Algunos equipos se quejaron de que frenaba la experimentación. Seguridad lo aprobaba. Operaciones lo amaba en silencio.

Un día, un repo de terceros rotó su clave de firma. Muchas empresas aprendieron esto cuando los despliegues en producción empezaron a fallar. En esta compañía, se detectó durante la build de imagen porque apt-get update falló inmediatamente en la pipeline. La solución se aplicó una vez (actualizar keyring + referencia signed-by), se incorporó en la imagen base y los despliegues continuaron con mínimo drama.

No evitaron el cambio del ecosistema. Evitaron el radio de impacto. La práctica era aburrida porque funcionaba, y funcionaba porque era aburrida.

Broma 2: Si mezclas stable, testing y unstable sin pinning, felicitaciones—has inventado una nueva distribución. Por favor, no publiques bugs sobre ello.

Errores comunes: síntoma → causa raíz → solución

1) “No se puede localizar el paquete …” después de una instalación limpia

Síntoma: Incluso paquetes comunes no se encuentran, o faltan paquetes de firmware.

Causa raíz: Las fuentes solo incluyen main, o las fuentes no se configuraron (instalación mínima, imagen personalizada).

Solución: Asegúrate de que existen repos de Debian e incluyen los componentes necesarios (main más non-free-firmware si necesitas firmware). Ejecuta apt-get update y verifica que se obtienen los índices de componentes.

2) El paquete existe en otro host pero no en este

Síntoma: Mismo “versión” del SO, resultado distinto.

Causa raíz: Diferentes etiquetas de suite (stable vs trixie), mirror distinto, o un host tiene índices obsoletos por advertencias en update.

Solución: Compara /etc/apt/sources.list* y la salida de apt-get update. Haz que el update esté libre de advertencias. Usa una estrategia de mirrors unificada.

3) Paquetes de repos de terceros “desaparecen” tras cambiar la suite

Síntoma: Tras migrar a Debian 13, paquetes de proveedor no se localizan.

Causa raíz: El repo del proveedor no publica para trixie (o publica solo bajo nombres en clave, no bajo stable).

Solución: Configura Suites: con el nombre en clave soportado por el proveedor; si no lo soportan, no lo fuerces—usa la release correcta o aísla mediante contenedores.

4) “No se puede localizar el paquete pkg:i386” en amd64

Síntoma: APT no localiza paquetes de arquitecturas foráneas.

Causa raíz: No se añadió la arquitectura i386; no se descargaron índices i386.

Solución: dpkg --add-architecture i386 y luego apt-get update. Verifica que se obtienen Packages i386.

5) Error tipográfico o nombre obsoleto de paquete

Síntoma: Todos juran que el nombre es correcto. No lo es.

Causa raíz: El paquete fue renombrado/dividido/eliminado entre suites.

Solución: Usa apt-cache search --names-only y apt-cache showpkg. Actualiza la automatización a los nombres nuevos.

6) El repo está presente pero ignorado por problemas de firma

Síntoma: Las líneas del repo existen; la instalación dice que no se puede encontrar el paquete.

Causa raíz: Falta la clave GPG o es incorrecta; signed-by mal configurado; el repo se trata como no confiable.

Solución: Arregla el keyring y la ruta de Signed-By; vuelve a ejecutar apt-get update hasta que esté limpio.

7) Entradas duplicadas / formatos mixtos causando confusión

Síntoma: Advertencias sobre objetivos configurados múltiples veces; candidatos inconsistentes.

Causa raíz: Entradas clásicas y deb822 que definen repos/suites superpuestos.

Solución: Consolida en un único enfoque de configuración. Elimina duplicados. Ejecuta update y confirma que no hay advertencias.

8) Mirror interno o proxy de caching sirviendo metadatos obsoletos

Síntoma: Update “funciona” pero la disponibilidad de paquetes es inconsistente entre redes.

Causa raíz: Falla de sincronización del mirror o semántica de caché para Release/Packages mal configurada.

Solución: Compara timestamps, evita el proxy para una prueba, arregla jobs de mirror, ajusta reglas de caché y monitorea la frescura de metadatos.

Listas de verificación / plan paso a paso

Checklist A: Recuperar la confianza en APT (higiene básica)

Ejecuta sudo apt-get update. Si hay advertencias/errores, detente y arréglalos.
Busca duplicados y conflictos en tu configuración de fuentes:
- grep -R sobre /etc/apt/sources.list*
Estandariza una estrategia única de nombres de suite:
- Usa nombres en clave para entornos de producción deterministas, especialmente en repos de terceros.
Usa keyrings por repo con signed-by (o Signed-By en deb822).
Documenta por qué se habilita cualquier componente no por defecto (non-free-firmware, non-free, contrib).

Checklist B: Diagnosticar un paquete específico faltante

Confirma el nombre en clave del SO: cat /etc/os-release.
Actualiza índices limpiamente: sudo apt-get update.
Comprueba la visibilidad del paquete:
- apt-cache policy <pkg>
- apt-cache show <pkg>
- apt-cache search --names-only
Confirma los componentes en tus entradas de Debian (main, quizá non-free-firmware).
Confirma la arquitectura:
- dpkg --print-architecture
- dpkg --print-foreign-architectures
Si es de terceros, valida el nombre de la suite y la confianza de firma de ese repo.

Checklist C: Evitar reintroducir el problema (flota/empresa)

Gate en CI: hacer fallar builds de imagen si apt-get update emite advertencias.
Un archivo canonical de sources, controlado por versión (deb822 preferido por claridad).
Estrategia de mirror:
- O mirrors oficiales por host, o mirror/proxy interno con monitoreo—no “lo que funcione hoy”.
Trata multiarch como una elección deliberada; no dejes que aplicaciones añadan i386 silenciosamente.
Auditoría periódica: volcado de sources y pines, comparar a través de la flota.

Preguntas frecuentes

1) ¿Por qué `apt update` tiene éxito pero `apt install` no puede localizar el paquete?

Porque apt update solo te dice que obtuvo algunos índices correctamente. Podrías estar sin la suite/componente/arch adecuada, o usando índices obsoletos tras fallos parciales.

2) ¿Cuál es la forma más rápida de saber si el paquete está en mis repos configurados?

Ejecuta apt-cache policy <pkg>. Si no hay Version table, APT no lo ve en los metadatos habilitados.

3) ¿Es Debian 13 especial aquí, o es simplemente APT siendo APT?

APT está siendo APT, pero las configuraciones en la era de Debian 13 incluyen con más frecuencia fuentes deb822, prácticas de keyring más estrictas y uso extendido de non-free-firmware, todo lo cual introduce nuevos modos de fallo.

4) ¿Debería usar `stable` o el nombre en clave (`trixie`) en las fuentes?

Para producción: prefiere nombres en clave para determinismo, especialmente en repos de terceros. Las etiquetas están bien para máquinas de desarrollador donde “seguir avanzando” es el objetivo.

5) Habilité `non-free-firmware`. ¿También necesito `non-free`?

No. Habilita lo mínimo que necesitas. El firmware suele ser suficiente; non-free es un contenedor más amplio con distintos tradeoffs.

6) Estoy en amd64 pero necesito un paquete i386. ¿Por qué APT no lo encuentra?

Porque APT no descargará índices de paquete i386 hasta que habilites multiarch con dpkg --add-architecture i386 y vuelvas a ejecutar apt-get update.

7) ¿Por qué veo advertencias sobre duplicados, y eso puede causar paquetes faltantes?

Los duplicados pueden causar selección de candidato confusa y ocultar desajustes reales de suite. También hacen que las personas interpreten mal la situación. Límpialos; trata “configurado múltiples veces” como un bug.

8) ¿Cuál es la forma correcta de manejar las claves de firma de repos de terceros ahora?

Usa un archivo keyring dedicado y refiérelo por repo con signed-by= (clásico) o Signed-By: (deb822). Evita cubos de confianza globales y patrones obsoletos de gestión de claves.

9) ¿Podría faltar un paquete porque mi mirror está fuera de sincronía?

Sí. Es menos común día a día, más común durante transiciones. Si otro mirror lo ve y tu update está limpio, sospecha sincronización del mirror o un proxy de caching sirviendo metadatos obsoletos.

10) ¿Cuándo “No se puede localizar el paquete” es realmente un error tipográfico?

Más a menudo de lo que nadie admite. Verifica con apt-cache search --names-only y deja de confiar en nombres medio recordados de lanzamientos anteriores.

Conclusión: próximos pasos que realmente puedes hacer hoy

Arreglar “No se puede localizar el paquete” en Debian 13 rara vez trata del paquete. Trata de hacer correctas las entradas de APT: suite, componente, arquitectura, firmas y metadatos actualizados.

Haz lo siguiente:

Haz que apt-get update no emita advertencias. No “más o menos bien”. Limpio.
Consolida tus fuentes en un conjunto coherente (evita conflictos silenciosos entre clásico y deb822).
Habilita explícitamente los componentes que requieres, especialmente non-free-firmware para firmware de hardware.
Verifica arquitectura y multiarch antes de culpar al repo.
Si manejas un mirror/proxy interno, trátalo como infraestructura de producción: monitorea frescura, no sensaciones.

Una vez que puedas explicar por qué APT ve el mundo como lo ve, “No se puede localizar el paquete” deja de ser una sorpresa y vuelve a ser lo que siempre fue: una auditoría de configuración con poca paciencia.