Crear y firmar paquetes .deb para distribuciones Linux

Crear y firmar paquetes .deb en Debian, Ubuntu y derivadas no es sólo cosa de desarrolladores veteranos. Con las herramientas adecuadas, algo de organización y entendiendo cuatro conceptos clave, cualquiera que se mueva con soltura por la terminal puede empaquetar su propio software y tenerlo bajo control, como un paquete más de la distribución.

Si estás cansado de instalar cosas en /usr/local o /opt sin control de paquetes, de tener binarios «huérfanos» que luego no recuerdas de dónde salieron, o de depender de que alguien empaquete por ti un programa del que sólo hay código fuente o un .tar.gz, aprender a crear paquetes .deb es la solución. Además, si rematas el trabajo con una buena firma GPG y, si quieres, tu pequeño repositorio, te quedará un sistema limpio, reproducible y fácil de mantener.

Qué es exactamente un paquete .deb y cómo se maneja

Un archivo con extensión .deb es el formato estándar de paquetes de Debian y de toda su familia: Ubuntu, Linux Mint, etc. Dentro lleva los binarios, bibliotecas, archivos de configuración, documentación y metadatos que describen cómo debe instalarse y gestionarse un programa.

El corazón del sistema es dpkg (Debian Package Manager), la utilidad de bajo nivel que instala, lista, comprueba y elimina paquetes .deb. Encima de él se apoyan herramientas más amigables como APT, aptitude o interfaces gráficas (Synaptic, GDebi, los centros de software, etc.) que añaden resolución automática de dependencias y una mejor experiencia de usuario.

A la hora de instalar un .deb ya hecho tienes varias opciones. Con dpkg:

sudo dpkg -i paquete.deb

Si aparecen errores de dependencias, se suelen corregir con:

sudo apt --fix-broken install

Con APT moderno puedes instalar directamente un archivo local y dejar que resuelva dependencias:

sudo apt install ./paquete.deb

Y si prefieres algo centrado en .deb, GDebi (en modo CLI o gráfico) es un instalador muy cómodo:

sudo apt install gdebi
sudo gdebi paquete.deb

Estructura interna básica de un paquete .deb

Un .deb es, en realidad, un archivo ar que contiene dos tarballs: control.tar.* y data.tar.*. Para construir uno «a mano» es más sencillo pensar en un árbol de directorios que después se empaqueta con dpkg-deb.

Imagina que quieres crear un paquete llamado fuentes-personales que instale tipografías en /usr/share/fonts/fuentes-personales. Primero montas un árbol como éste en un directorio de trabajo:

fuentes-personales/
  DEBIAN/
  usr/share/fonts/fuentes-personales/

La carpeta DEBIAN (nombre obligatorio en mayúsculas) contendrá los metadatos y scripts de control; el resto del árbol replica exactamente la ruta final en el sistema donde quedarán los archivos instalados. Dentro de usr/share/fonts/fuentes-personales/ pondrías las fuentes en sí.

En el directorio DEBIAN hay varios archivos clave que debes conocer:

• control: ficha técnica del paquete (nombre, versión, dependencias, descripción, etc.).
• postinst: script que se ejecuta después de la instalación o desempaquetado.
• postrm: script que se lanza después de la eliminación del paquete.
• conffiles: lista de archivos de configuración gestionados con especial cuidado en actualizaciones.

Los scripts de mantenimiento como postinst y postrm deben ser ejecutables, con permisos entre 0555 y 0755. Suelen ser scripts de shell, aunque no hace falta poner necesariamente la línea #!/bin/bash si se usan desde dpkg.

Archivo DEBIAN/control: campos imprescindibles y relaciones

El fichero DEBIAN/control es el corazón declarativo del paquete. Aquí van el nombre, la versión, el mantenedor, la arquitectura, la descripción y, muy importante, las dependencias y relaciones con otros paquetes.

Para un paquete sencillo de fuentes, un control mínimo podría parecerse a esto (a modo de ejemplo, reescrito):

Package: fuentes-personales
Version: 1.0-3
Section: misc
Priority: optional
Maintainer: Nombre Apellido <[email protected]>
Architecture: all
Replaces: fuentes-personales (<= 1.0-2)
Description: Colección de fuentes personales
Instala un conjunto de tipografías adicionales para el sistema.

Algunos campos clave que conviene dominar:

• Package: nombre del paquete binario (sin espacios, en minúsculas, longitud razonable).
• Version: normalmente version_upstream-revision (por ejemplo 1.0-3).
• Section: categoría en el archivo (admin, devel, net, x11, games, libs, misc, etc.).
• Priority: importancia (required, important, standard, optional, extra).
• Architecture: any (compilado según arquitectura), all (independiente, p. ej. fuentes, scripts), o una arquitectura concreta (amd64, i386…).
• Depends, Recommends, Suggests, Conflicts, Provides, Replaces, Pre-Depends: relaciones entre paquetes.

El sistema de dependencias de Debian es muy fino. Con Depends obligas a que otros paquetes estén instalados para que este funcione; con Recommends y Suggests das pistas a APT y dselect sobre paquetes que complementan el tuyo; con Conflicts y Replaces controlas paquetes incompatibles o que comparten archivos; y con Provides anuncias que ofreces una funcionalidad «virtual» (como «mail-transport-agent»).

Para las bibliotecas compartidas, se suele usar ${shlibs:Depends} en Depends, que luego será sustituido automáticamente por dh_shlibdeps al generar el paquete, según las libs que realmente usa tu binario.

Construir un .deb de forma manual con dpkg-deb

Si ya tienes el árbol de directorios listo, con DEBIAN/control bien rellenado y los archivos en su sitio, crear el .deb con herramientas básicas es muy directo:

dpkg-deb -b fuentes-personales

Esto generará fuentes-personales.deb, un paquete instalable. Puedes inspeccionar sus metadatos con:

dpkg --info fuentes-personales.deb

Y verás algo del estilo: tamaño, control, scripts postinst/postrm (si existen), y el contenido resumido. Para ver el árbol de archivos dentro del paquete, basta con:

dpkg -c fuentes-personales.deb

Una vez satisfecho, instalas como cualquier otro:

sudo dpkg -i fuentes-personales.deb

y compruebas que, en este ejemplo, las fuentes se han colocado en /usr/share/fonts/fuentes-personales tal y como esperabas.

Herramientas de desarrollo para empaquetar software complejo

Cuando pasas de paquetes simples (como un puñado de fuentes) a aplicaciones completas con compilación, bibliotecas, documentación y demás, conviene apoyarse en todo el ecosistema de herramientas de desarrollo de Debian.

Algunos paquetes imprescindibles para desarrollar .deb de programas «serios»:

• dpkg-dev: herramientas para desempaquetar, construir y subir paquetes fuente.
• binutils, gcc, make, libc6-dev: el toolchain de compilación estándar en C/C++.
• autoconf, automake, autotools-dev: soporte para proyectos con sistema «configure & make».
• debhelper, dh-make: colección de scripts que automatizan el empaquetado.
• devscripts: utilidades para mantenedores (debuild, uscan, dch, etc.).
• fakeroot: emula root durante la construcción sin necesidad de privilegios reales.
• lintian, linda: comprobadores automáticos de calidad de paquetes.
• debian-policy, developers-reference: documentación oficial de cómo deben ser los paquetes.

La idea es que no vayas ejecutando dpkg-deb -b a pelo para cualquier cosa medianamente compleja. En su lugar, usas el flujo Debian estándar: paquete fuente, directorio debian/ con reglas, y construcción mediante dpkg-buildpackage o debuild.

Del código fuente al paquete Debian: flujo general

El proceso «tipo» que sigue la Guía del Nuevo Mantenedor de Debian se puede resumir así (simplificando pero sin dejar piezas importantes fuera):

1. Instalar las herramientas de empaquetado (las que acabamos de listar).
2. Descargar y probar el programa desde la fuente original (tar.gz, etc.), compilarlo, instalarlo en /usr/local y ver que funciona.
3. Preparar un directorio de trabajo, normalmente en /usr/local/src/nombre, descomprimir ahí el código y, si hace falta, renombrar a algo del estilo nombre-versión.
4. Adaptar el proyecto a la jerarquía de Debian: nada en /usr/local, todo bajo /usr, /etc, /var según FHS.
5. Crear el esqueleto Debian con dh-make, que añadirá un directorio debian/ con plantillas.
6. Rellenar y ajustar los archivos de debian/: control, rules, copyright, changelog, conffiles, etc.
7. Construir el paquete con dpkg-buildpackage, preferiblemente usando fakeroot.
8. Revisar el .deb con lintian y linda, corregir problemas y reconstruir hasta que quede limpio.
9. Probar la instalación, actualización y desinstalación en una máquina o jaula limpia (chroot, pbuilder, cowbuilder).
10. (Opcional) Subir el paquete a un repositorio y, si procede, a Debian/Ubuntu a través del flujo oficial.

Este flujo se complementa con buenas prácticas como usar un sistema de control de versiones (Subversion, Git, etc.), preparar una jaula chroot limpia con pbuilder/cowbuilder para reproducir construcciones, y montar un pequeño repositorio APT local con reprepro para distribuir tus propios .deb y probar que APT los ve correctamente.

Trabajar con dh-make, debhelper y debian/rules

El primer gran salto viene cuando dejas los paquetes «manuales» y adoptas el estándar Debian basado en debhelper y un fichero debian/rules, que es un Makefile especial que describe cómo se compila e instala el paquete.

Partes de las fuentes del programa (por ejemplo, gentoo-0.9.12/) y ejecutas:

dh_make

Te preguntará qué tipo de paquete quieres (binario simple, multibinario, librería, etc.) y te creará un directorio debian/ con plantillas: control, rules, copyright, changelog, ejemplos de scripts, ficheros .docs, .menu, .manpage.ex, etc.

El archivo debian/rules generado con debhelper contiene objetivos como build, clean, install, binary-arch y binary-indep. En la parte de binary-arch se invoca una batería de comandos dh_*:

• dh_installdocs: instala documentación en /usr/share/doc/paquete.
• dh_installexamples: copia ejemplos a la carpeta correspondiente.
• dh_installmanpages: coloca las páginas de manual y sus enlaces.
• dh_installchangelogs: instala los registros de cambios.
• dh_strip, dh_compress, dh_fixperms: optimización del tamaño y permisos correctos.
• dh_shlibdeps, dh_gencontrol, dh_builddeb: cálculo de dependencias, creación de control y construcción final del .deb.

La gracia está en que estos scripts leen otros archivos bajo debian/ (por ejemplo paquete.docs, paquete.manpages, etc.) y actúan en consecuencia. Así tu debian/rules puede ser bastante corto y legible, y si luego cambias algo, sólo tienes que ajustar los ficheros auxiliares.

Control de calidad: lintian, linda y pruebas en entornos limpios

Que el paquete se compile e instale en tu máquina no significa que esté bien. Para acercarte a los estándares de Debian, es fundamental pasarle herramientas de análisis estático como lintian y linda.

Por ejemplo:

lintian -i paquete_1.0-1_i386.deb
linda -i paquete_1.0-1_i386.deb

Ambas herramientas sacan avisos (W) y errores (E) con explicaciones bastante detalladas. Detectan problemas típicos como:

• Páginas man instaladas en /usr/man en lugar de /usr/share/man (quebranta el FHS).
• Licencias duplicadas en /usr/share/doc que deberían ir sólo en debian/copyright.
• Script de mantenimiento con errores, permisos incorrectos o llamadas a herramientas obsoletas.
• Paquetes que rompen la política de secciones, prioridades o estructura de archivos.

Además, se recomienda encarecidamente probar el paquete en una jaula chroot creada con pbuilder/cowbuilder, donde sólo se instalarán las dependencias declaradas. Esto permite detectar dependencias olvidadas (cosas que tienes en tu sistema pero no has declarado en control) y comprobar el proceso de instalación, actualización y purga en un entorno reproducible.

Firmar paquetes y repositorios con GPG

Si vas a distribuir tus .deb a otras personas, no es buena idea hacerlo sin más. Lo ideal es firmar tus paquetes y tu repositorio con una clave GPG, de manera que los usuarios puedan comprobar que lo que instalan viene realmente de ti y no ha sido modificado por el camino.

El esquema es sencillo: generas una clave GPG (par de claves pública/privada), usas la privada para firmar, y publicas la pública para que el resto la importe. Lo que se suele firmar no es el .deb directamente, sino los ficheros de cambios (.changes), los descriptores de fuente (.dsc) y el archivo Release del repositorio.

En un repositorio APT montado con reprepro, por ejemplo, el fichero dists/<distribución>/Release se acompaña de Release.gpg, que es la firma. Cuando un usuario añade tu repositorio e importa tu clave, APT verifica automáticamente esa firma cada vez que actualiza la lista de paquetes. Si algo no cuadra (archivo manipulado, clave errónea), APT lanza un aviso de seguridad y no se fía.

Para el desarrollador, la integración ideal es usar debuild o pdebuild con auto-debsign, de forma que al terminar de construir paquetes pida la contraseña de la clave GPG y firme los archivos necesarios sin que tengas que ir uno a uno.

Repositorios locales y publicación: reprepro, Apache, rsync…

Una vez que tienes varios paquetes, mantenerlos uno a uno es un engorro. Lo natural es crear tu propio repositorio APT local, aunque sea en tu máquina o en un servidor casero. Así cualquier cliente (incluyéndote a ti mismo) podrá usar apt install paquete como con cualquier repositorio oficial.

Hay varias herramientas para ello, pero una muy popular es reprepro, que se encarga de generar toda la estructura de dists/ y pool/, el archivo Release y su firma. El flujo típico consiste en:

• Crear un árbol base, por ejemplo /var/packages/ubuntu.
• Configurar las distribuciones (gutsy, stable, testing, etc.) en los archivos de reprepro.
• Añadir paquetes binarios con includedeb y fuentes con includedsc.
• Firmar el Release con tu clave GPG.

Para publicar el repositorio en red, basta con exponer ese directorio vía Apache o cualquier otro servidor HTTP/FTP. Después, en los clientes, se añade una línea a /etc/apt/sources.list o a los diálogos gráficos de «Orígenes de software», algo como:

deb http://tuservidor/ubuntu gutsy main
deb-src http://tuservidor/ubuntu gutsy main

y se importa la clave pública (apt-key add claveDebian.asc o mediante la interfaz gráfica). A partir de ahí, el repositorio funcionará igual que cualquier otro, con actualizaciones automáticas incluidas.

Si tu equipo no está siempre encendido o no puedes ofrecer HTTP directamente, otra opción es sincronizar el contenido de /var/packages a un proveedor de hosting mediante lftp mirror, rsync o similar, de forma que el servidor público sea el que sirve el repositorio, pero tú lo generas y actualizas en local.

Conversión entre formatos y alternativas cuando no hay .deb

Aunque estés en Debian/Ubuntu, tarde o temprano te toparás con software empaquetado sólo en otros formatos. La utilidad alien permite convertir entre .deb, .rpm, paquetes Slackware, LSB, etc. No produce artefactos tan pulidos como un empaquetado nativo, pero sirve para salir del paso.

Ejemplos prácticos:

• Convertir cualquier formato a .deb: sudo alien archivo.rpm → genera archivo.deb.
• Pasar de .deb a .rpm: sudo alien --to-rpm paquete_1.0-1_i386.deb.

Hay que revisar lo que sale (scripts de mantenimiento, rutas, dependencias), pero para software sin versión nativa puede ser muy útil. Otra alternativa cómoda cuando compilas algo tú mismo es checkinstall, que engancha la fase de make install, registra lo que se copia y construye un .deb básico que instala inmediatamente. No es válido para repos oficiales, pero te evita tener cosas fuera del control de dpkg.

Para módulos Perl del CPAN, otra herramienta específica es dh-make-perl, que genera un esqueleto de paquete Debian a partir del módulo (por ejemplo dh-make-perl --cpan XML::Writer) para que puedas integrarlo en tu sistema como un .deb más.

En conjunto, dominar la construcción y firma de paquetes .deb para distribuciones Linux basadas en Debian te da mucho más que la capacidad de instalar un programa: te permite versionar tus propios desarrollos, desplegarlos con seguridad, auditar lo que hay en tus máquinas y, si te animas, contribuir al ecosistema enviando tus paquetes a los repositorios oficiales o compartiéndolos mediante tu propio archivo APT firmado.