DEB822: el nuevo formato de sources.list en Debian (y derivadas)
Hoy vamos a aprender a configurar los repositorios online de nuestras distros basadas en Debian (DEB) utilizando el nuevo formato DEB822, en lugar del anterior formato de estilo de una línea, clásico en estas distros.
Introducción
Las distros Debian y derivadas, como Ubuntu o Mint, usan apt como gestor de paquetes, dependencias y actualizaciones.
Estas distros configuran los repositorios remotos en el archivo /etc/apt/sources.list, o archivos incluidos dentro de /etc/apt/sources.list.d.
Allí se especifican las URIs de los repositorios, protocolos de aplicación, componentes, etc.
En la mayoría de las distros basadas en DEB estos archivos se configuran con el clásico formato de una línea por repositorio (One-Line-Style Format).
A partir de Debian 13 «Trixie» y algunas derivadas, el formato de los archivos de configuración de repositorios cambió a uno nuevo, basado en bloques de configuración por repo, llamado «Deb822» (Deb822-style Format).
Vamos a ver en qué difiere del anterior, y cómo realizar la conversión.
Directorio /etc/apt/sources.list.d
Este directorio almacena archivos de configuración de repositorios. Podemos tener varios archivos, y cada uno a su vez puede configurar uno o más repositorios.
Esto sirve para organizar los repositorios en archivos temáticos, por ejemplo, repositorios base de Debian, repositorios de navegadores, o de alguna app particular, etc.
Con el formato clásico de una línea, cada archivo tenía la extensión «.list«. Ahora, con Deb822, esos archivos tendrán la extensión «.source«. Este cambio le indica a las herramientas de gestión de paquetes APT cómo obtener la información de los repositorios online.
Nota:
Estamos hablando de la configuración de los repositorios, no cambia nada el uso de los comandos para actualizar o instalar paquetes, apt
en este caso, el cambio de formato es transparente para el usuario.
Formato de una línea – One-Line-Style Format
Repasemos el formato anterior para entender el nuevo.
En este tipo de formato se usa una sola línea de configuración por repositorio, donde se especifican todos los parámetros de configuración.
Las líneas comienzan con un deb
para indicar un repositorio de binarios, o deb-src
para repositorio de código fuente.
Seguido de esto indicamos la URI del repositorio, componentes, y otras opciones de configuración, todo en una misma línea de configuración.
Las líneas vacías son ignoradas, y las líneas que comienzan con #
también, pero estas nos permiten añadir comentarios a las configuraciones.
Podemos añadir opciones separándolas con espacios dentro de un grupo de corchetes [ ]
. Si las opciones soportan varios valores, éstos se separarán con coma, y se separarán del nombre de la opción con =
.
Veamos un ejemplo simple:
deb [arch=amd64] https://download.docker.com/linux/debian bullseye stable
deb-src [arch=amd64] https://download.docker.com/linux/debian bullseye stable
Este es el formato tradicional de configuración de repositorios actualmente soportado por APT.
Desventajas del formato de una línea
El problema con este formato comienza al parsear las entradas por APT.
Las líneas de configuración tradicionales, sin opciones, son relativamente fáciles de parsear, no obstante, cuando comenzamos a cargar opciones, con valores simples o múltiples, el parseo se complica.
Si a esto le sumamos que el formato soporta varios esquemas de URIs, extensiones, etc.
En la actualidad, el análisis de una línea de sources.list require de varios niveles de parseo, uso de expresiones regulares, etc.
Veamos estos ejemplos:
deb [] http://example.com.ubuntu disco main restricted multiverse universe
deb [ arch=amd64 ] http://example.com/ubuntu disco main nonfree
deb [lang=en_US] http://example.com/ubuntu disco main restricted universe multiverse
deb [ arch=amd64,armel lang=en_US,en_CA ] http://example.com/ubuntu disco main
Cada entrada es válida, pero cada una tiene un formato distinto. una con los corchetes de opciones vacío, otra con una opción, otra con dos opciones con múltiples valores cada una, y además, cada línea con sus propios componentes (main, nonfree, etc.).
Por otro lado, una limitación de este formato es que cada línea de configuración puede especificar solamente una URI, por lo que, si tenemos un mirror de un repositorio, deberemos cargar dos veces la misma línea, cambiando la URI en cada una.
Así es que, además de la dificultad de parsear configuraciones, el formato tiene limitaciones, y obliga al usuario a duplicar entradas, dificultando su mantenimiento y gestión.
Formato Deb822 (Deb822-style Format)
El objetivo de este formato es solucionar los problemas del formato de una sola línea, como la duplicación de líneas, o la dificultad de parseo de las entradas.
En este formato tenemos bloques de configuración, donde cada bloque representa un repositorio. Estos bloques permiten listas de valores en las opciones, permitiendo añadir los mirrors de un repositorio dentro del mismo bloque, evitando duplicación.
Un bloque de configuración contiene varias líneas, todas con el mismo formato, lo que facilita el parseo por parte de APT.
Además, un dato interesante, es que uno puede añadir opciones y valores nuevos, que APT no reconoce y va a ignorar sin generar errores. Esto es útil para añadir datos como versiones, comentarios, etc., que podemos usar con aplicaciones de terceros para realizar otros procesamientos.
Se mantienen, igual que en el formato anterior (y en casi todos los archivos de configuración en Linux), el caracter ‘#
‘ al inicio de la línea para indicar comentarios. Podemos usar este caracter para deshabilitar una línea o configuración, aunque, como lo permite la herramienta, es más elegante (si se quiere) añadir una opción «Enabled:no
» para desactivarla, y cambiarla a «Enabled:yes
» (o eliminarla, el default en ‘yes
‘) cuando deseemos activarla.
Campos de un bloque DEB822
Veamos los campos de un bloque Deb822 para poder configurarlo correctamente.
Campo | Descripción | Valores | Requerido |
Enabled | Le dice a APT que el repo está habilitado o no. | «yes » o «no « | No, default: «yes « |
Types | Define el tipo de paquetes que brinda el repo, si se trata de binarios pre-compilados, o fuentes. | «deb » o «deb-src « | Si |
URIs | Dirección donde se encuentra la base de archivos del repo. Pueden ser varias separadas por espacio. | La URI del repositorio. | Si |
Suites | Puede tener el codename de la distro («trixie», «bullseye», etc), o la ruta completa al repo, terminada con «/» y omitir «Components». | Cadenas de caracteres (Strings) | Si |
Components | Secciones de la versión presente en la Suite. | Cadenas de caracteres (Strings) | Si Suites especifica un codename, sí. Si Suites especifica una ruta, debe omitirse Components. |
Cada uno de estos parámetros se separa de los valores con «:
«. Veamos un ejemplo simple:
Types: deb deb-src
URIs: https://deb.debian.org/debian
Suites: bookworm bookworm-updates
Components: main non-free-firmware
Enabled: yes
Aquí pueden verse todos estos parámetros configurados para un Debian 12. Puede verse el tipo de repositorio (deb
y deb-src
), la URI, el codename de la distro, los components, y el repo habilitado.
Opciones adicionales
El formato DEB822 permite añadir opciones extra, una por linea, con la misma sintaxis de los demás parámetros, indicando el nombre de la opción, el separador «:
«, y el o los valores separados por espacio.
Veamos algunas de las opciones comunes:
Architectures
(arch): permite especificar las arquitecturas, separadas por espacio.Languages
(lang): Permite especificar los lenguajes, separados por espacio.Signed-By
(signed-by): Permite especificar la firma digital para verificar la confiabilidad del repo.
Veamos estas opciones en un ejemplo:
Types: deb deb-src
URIs: https://deb.debian.org/debian
Suites: bookworm bookworm-updates
Components: main non-free-firmware
Architectures: amd64
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Language: en
Enabled: yes
Migración al nuevo formato Deb822
Sí, podemos migrar nuestros repositorios al nuevo formato Deb822 realizando la traducción automáticamente.
Para ello debemos modernizar los repos utilizando apt
:
$ sudo apt modernize-sources
Este comando creará backups de los repositorios actuales, y creará los nuevos, cambiando el formato «.list
» a «.source
«.
Veamos un ejemplo de ejecución en Kali Linux, derivado de Debian.
En mi caso, tengo estos repositorios online:
└─$ tail -n +1 /etc/apt/sources.list.d/* /etc/apt/sources.list
==> /etc/apt/sources.list.d/mozilla.list <==
deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main
==> /etc/apt/sources.list <==
# See https://www.kali.org/docs/general-use/kali-linux-sources-list-repositories/
deb http://http.kali.org/kali kali-rolling main contrib non-free
# Additional line for source packages
deb-src http://http.kali.org/kali kali-rolling main contrib non-free
Si ejecutamos el modernizador de repos:
└─$ sudo apt modernize-sources
The following files need modernizing:
- /etc/apt/sources.list
- /etc/apt/sources.list.d/mozilla.list
Modernizing will replace .list files with the new .sources format,
add Signed-By values where they can be determined automatically,
and save the old files into .list.bak files.
This command supports the 'signed-by' and 'trusted' options. If you
have specified other options inside [] brackets, please transfer them
manually to the output files; see sources.list(5) for a mapping.
For a simulation, respond N in the following prompt.
Rewrite 3 sources? [Y/n]
Nos informa que se crearán los archivos .source, y se crearán los backups de los archivos .list, añadiendo la extensión «.bak».
Si le decimos que sí (Y) realizará los cambios. Si le decimos que no (N) realizará una simulación y veremos por pantalla los cambios que haría el comando.
En mi caso realicé la migración, el archivo /etc/apt/sources.list ya no se utilizará más, se guardó como backup renombrado a /etc/apt/sources.list.bak, y el contenido fue movido, utilizando el nuevo formato, dentro de /etc/apt/sources.list.d.
Todos los repositorios ahora están dentro de /etc/apt/sources.list.d/, con extensión .source (los nuevos) y .bak (los backups de los viejos).
Veamos qué contenido tienen los nuevos:
└─$ tail -n +1 /etc/apt/sources.list.d/*.sources
==> /etc/apt/sources.list.d/kali.sources <==
# Modernized from /etc/apt/sources.list
Types: deb deb-src
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg
==> /etc/apt/sources.list.d/mozilla.sources <==
Types: deb
URIs: https://packages.mozilla.org/apt/
Suites: mozilla
Components: main
Signed-By: /etc/apt/keyrings/packages.mozilla.org.asc
Comparen cada entrada de repositorio .source con las entradas de una línea del repositorio anterior para ver cómo la misma información está escrita con el nuevo formato.
Un cambio interesante: en los archivos .list anteriores tenía dos repositorios para Kali, el deb
y el deb-src
, que compartían la URI. Ahora tengo un solo bloque de repositorio, con los dos «Types
«: deb
y deb-src
.
Luego de ejecutar un «sudo apt update
» para que actualice los repos, me di cuenta que tenía errores con las claves. Faltaba una clave:

Investigando un poco en la red, encontré el comando para descargar la nueva clave desde el repositorio de claves de Kali:
$ sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg
Y luego, el sudo apt update
salió andando perfecto!
Esto de las claves cambia dependiendo del repo. En este caso fue simple por que se trataba del repo oficial de Kali, habrá que buscar para cada clave y repositorio, la URL para su descarga.
Y hemos llegado al final de lo que parecía un artículo «corto» xD
Ahora ya sabemos cómo migrar y gestionar nuestros repositorios usando el formato DEB822 en nuestras distros basadas en Debian.
El mayor problema que me he topado ha sido el tema de las claves, a veces cuesta un poco encontrar los servidores de clave para añadirlas a nuestro sistema, eso depende del proveedor del repositorio, por lo que cada proveedor debería brindarnos, en su documentación, los pasos necesarios para añadir las claves, y evitar, de esa forma, las advertencias de verificación de firma.
Ah, me olvidaba, existen otras opciones, y otros formatos para las URIs, y mucha mucha documentación, todo explicado perfectamente en nuestra terminal de comandos 🙂
man 5 sources.list
Espero que les sea útil!
Hasta la próxima!