Cómo crear un paquete .deb paso a paso

Si usas Debian, Ubuntu o cualquier derivada, tarde o temprano te puede apetecer crear tu propio paquete .deb para instalar scripts, binarios, fondos de pantalla o cualquier otro recurso de forma limpia y repetible. Empaquetar bien no solo queda “pro”, también te ahorra tiempo cuando quieres desplegar lo mismo en varias máquinas o compartirlo con otros usuarios.

Aunque al principio pueda sonar un poco enrevesado, la realidad es que el formato .deb sigue unas reglas muy claras: una estructura de directorios concreta, unos archivos de control con información del paquete y, opcionalmente, unos scripts de mantenimiento que se ejecutan en distintas fases de la instalación o desinstalación. Entendiendo estos conceptos básicos, podrás fabricar desde el típico .deb que copia un script en /usr/bin hasta paquetes más elaborados con fuentes, fondos de pantalla o aplicaciones completas compiladas desde código fuente.

Qué es exactamente un paquete .deb

Un archivo con extensión .deb es el formato de paquete de software que usa Debian y todas sus derivadas (Ubuntu, Deepin basada en Debian, etc.). Dentro de ese archivo se encuentran, comprimidos, los ficheros que se instalarán en tu sistema y una serie de metadatos que describen el paquete: nombre, versión, arquitectura, dependencias, scripts postinstalación, etc.

El programa de bajo nivel que gestiona estos paquetes es dpkg, que se encarga de desempaquetar, instalar, configurar y eliminar los .deb. Encima de él trabajan herramientas más cómodas como apt, aptitude o gestores gráficos tipo Synaptic, PackageKit, Gdebi o el Centro de Software de Ubuntu. Pero al crear un .deb a mano, trabajarás casi siempre con dpkg y dpkg-deb.

A nivel práctico, un paquete .deb no es más que un archivo instalable en sistemas Debian que integra todo lo necesario para desplegar correctamente una aplicación o recursos. Frente a un simple tar.gz o a un AppImage, el .deb se integra con el sistema de paquetes, respeta rutas estándar y permite gestionar dependencias y versiones de forma ordenada.

Estructura básica de un paquete .deb

Antes de empaquetar nada, es fundamental entender que un .deb se construye a partir de una carpeta raíz cuyo nombre suele coincidir con el del paquete (por ejemplo miapp, fuentes-personales, deb, etc.). Dentro de esa carpeta tenemos dos grandes bloques: la carpeta DEBIAN (en mayúsculas) y la jerarquía de instalación donde se copiarán los archivos del paquete.

La carpeta DEBIAN contiene los archivos de control del paquete. El obligatorio es control, donde se definen el nombre del paquete, la versión, la arquitectura, las dependencias, la descripción, etc. Además, se pueden crear scripts especiales como postinst y postrm, que se ejecutan automáticamente tras instalar o eliminar el paquete.

El resto de la estructura replica las rutas del sistema donde quieres que terminen tus archivos. Si quieres instalar un script en /usr/bin, deberás crear miapp/usr/bin/ y colocar allí el ejecutable. Si son fuentes, usarás /usr/share/fonts/. Si son fondos de pantalla, quizá /usr/share/backgrounds/. El empaquetador se limita a desempaquetar el contenido del .deb en esas rutas, respetando la jerarquía.


mkdir deb
mkdir -p deb/usr/bin
cp execute.sh deb/usr/bin/


Después, dentro de deb, crearías deb/DEBIAN/ y el archivo deb/DEBIAN/control con los metadatos del paquete. Esa estructura será la que luego se empaquete con dpkg-deb o dpkg -b para generar el .deb final.

El archivo de control: corazón del paquete

Dentro de la carpeta DEBIAN es obligatorio el fichero control, que define toda la información básica del paquete. Es un archivo de texto plano sin extensión que contiene campos en formato Clave: Valor, uno por línea. Algunos de los campos más habituales son:


Package: nombre-del-paquete
Version: 1.0
Section: misc
Priority: optional
Architecture: all
Maintainer: Nombre Apellido <email@dominio>
Depends: paquete1, paquete2
Replaces: paquete-viejo (>= 1.0)
Description: descripción corta
descripción larga del paquete en una o varias líneas


El campo Package indica el nombre interno del paquete y no admite espacios ni guiones bajos. Se suelen usar solo minúsculas, números y guiones normales (-). Es el nombre que verá el sistema de paquetes al instalarlo.

El campo Version marca la versión concreta del paquete y es importante ir actualizándolo cuando hagas cambios significativos. Puede seguir un formato simple como 1.0 o más elaborado tipo 1.0-3 para indicar revisiones dentro de la misma versión de software. Si necesitas revertir cambios, aprende a volver a una versión anterior de un paquete.

Los campos Section y Priority ayudan a clasificar el paquete. Section puede ser algo tipo misc, custom, net, etc., especialmente útil si piensas publicar el paquete en un repositorio. Priority refleja la importancia: valores habituales son required, important, standard, optional o extra, siendo optional el más común para paquetes personalizados.

El campo Architecture especifica para qué arquitectura va dirigido el paquete: amd64, i386, x86, arm64, etc. Si el paquete contiene solo scripts o archivos independientes de la arquitectura (como imágenes, fuentes o scripts en bash o Python), puedes usar all para indicar que funciona en cualquier plataforma.

En Maintainer se indica el desarrollador o responsable del paquete, normalmente con nombre y correo electrónico. El campo Replaces sirve para señalar paquetes o versiones que este nuevo paquete sustituye, algo útil cuando sacas una versión nueva que debe reemplazar a otra anterior instalada. Si prefieres mantener varias versiones, consulta cómo instalar dos versiones del mismo paquete en Linux.

El campo Depends lista las dependencias que deben estar instaladas antes o durante la instalación del paquete. Por ejemplo, si tu aplicación está escrita en Python y no te encargas tú mismo de instalar las librerías desde un script, puedes indicar aquí los paquetes necesarios para que apt los resuelva automáticamente. Si tu paquete ya se busca la vida (por ejemplo, descargando dependencias desde un script de instalación), puedes dejar Depends: vacío.

Por último, el campo Description tiene truco: la primera línea contiene una descripción corta, y las siguientes líneas (opcionalmente) forman la descripción larga. Es obligatorio que cada línea de la descripción larga comience con un espacio en blanco antes del texto. Eso permite que las herramientas de Debian distingan ambas partes y muestren la información correctamente en listados y gestores de paquetes.

Scripts postinst y postrm: automatizando tareas

Además del fichero control, en la carpeta DEBIAN puedes crear varios scripts de mantenimiento que se ejecutan de forma automática en diferentes momentos. Los más usados en paquetes sencillos son postinst y postrm, aunque existen otros como preinst o prerm para casos más avanzados.

El script postinst se ejecuta después de desempaquetar e instalar los archivos. Es el sitio ideal para lanzar comandos de configuración: por ejemplo, ejecutar un instalador propio de tu aplicación, regenerar cachés, recargar servicios o modificar algún archivo de configuración generado durante la instalación.

El script postrm se ejecuta después de eliminar el paquete. Suele utilizarse para limpiar archivos residuales que no forman parte estricta del paquete o para desmontar cambios hechos en la configuración del sistema. Por ejemplo, podrías borrar una carpeta creada en /usr/share/fonts/fuentes-personales/ tras desinstalar un paquete de fuentes.

Estos scripts son simplemente archivos de texto ejecutables que contienen los comandos a lanzar, normalmente en bash. No es obligatorio añadir la línea #!/bin/bash al principio, aunque es una buena práctica. Es importante que tengan permisos de ejecución correctos, normalmente algo como 755 (es decir, lectura y ejecución para todos, escritura solo para el propietario). En general, se recomienda que estén entre 0555 y 0755.


#!/bin/bash
rm -Rf /usr/share/fonts/fuentes-personales/


Con esto, al eliminar el paquete mediante dpkg -r o apt remove, el directorio indicado desaparecerá automáticamente, evitando restos innecesarios en el sistema.

Creación de la jerarquía de directorios del paquete

Para que el paquete funcione como esperas, tienes que reproducir dentro de tu carpeta raíz la estructura exacta donde quieras que se instalen los archivos. La idea es que lo que pongas en miapp/usr/bin/ acabará en /usr/bin/, lo que haya en miapp/usr/share/fonts/ terminará en /usr/share/fonts/ y así sucesivamente.

Imagina que quieres crear un paquete que instale nuevas fuentes tipográficas para tu sistema. El árbol de directorios podría ser algo como:


fuentes-personales/
├── DEBIAN/
│ └── control
└── usr/
└── share/
└── fonts/
└── fuentes-personales/
├── fuente1.ttf
└── fuente2.otf


En este caso, al instalar el paquete, las fuentes se copiarán a /usr/share/fonts/fuentes-personales/. Si más adelante sacas una nueva versión con fuentes adicionales o mejoradas, solo tendrías que actualizar el contenido de esa carpeta y subir la versión en el fichero control.

Otro escenario típico es empaquetar un script descargado de GitHub, por ejemplo una herramienta que quieras colocar en /opt y quizá añadir un lanzador en /usr/bin. Podrías descargar el proyecto (por ejemplo 4nonimizer), crear una carpeta deb/opt/ y meter ahí el código completo:


mkdir -p deb/opt/
cp -R 4nonimizer deb/opt/


Si además quieres que, al instalar el paquete, se ejecute un comando tipo 4nonimizer install, podrías usar un script postinst que lance esa orden automáticamente tras desempaquetar los archivos. Así consigues que el usuario solo tenga que instalar el .deb y listo, sin pasos manuales adicionales.

No olvides que, antes de construir el paquete, es muy recomendable que el propietario de toda la carpeta raíz sea root, ya que, en ejecución real, los archivos del sistema pertenecen a este usuario. Puedes ajustar la propiedad con:


sudo chown -R root:root ./deb


Generar el paquete .deb de forma manual

Una vez tienes preparada la estructura con la carpeta DEBIAN, el archivo control, los posibles scripts postinst/postrm y la jerarquía donde van los archivos, el siguiente paso es construir el paquete .deb. Hay varias formas de hacerlo, pero las más habituales para paquetes sencillos son dpkg -b y dpkg-deb –build.


dpkg -b ./deb /home/usuario/SCRIPTS.deb


Para el caso de la aplicación miapp, la orden habitual sería algo como:


cd ruta/donde/este/miapp
dpkg-deb --build miapp


Esto creará un archivo de nombre similar a miapp.deb o, dependiendo de cómo lo hayas configurado y desde dónde lo lances, un archivo siguiendo un patrón tipo miapp-1.0_amd64.deb. Ese archivo será ya el paquete instalable que podrás copiar a otras máquinas o subir a un repositorio.

Tras la construcción, puedes inspeccionar la información interna del paquete con:


dpkg --info fuentes-personales.deb


El comando mostrará datos como el tamaño, las secciones, la prioridad, el mantenedor, la arquitectura, la descripción corta y larga, así como referencias a los scripts de mantenimiento (por ejemplo, postinst o postrm) si los has incluido.

Instalar y probar tu paquete .deb

Una vez generado el archivo .deb, llega el momento de probar que realmente hace lo que esperas. Puedes instalarlo desde un entorno gráfico, usando herramientas como GDebi o el instalador de paquetes de tu distribución, o directamente desde la terminal.


sudo dpkg -i nombre-del-paquete.deb


Si tu sistema te avisa de dependencias rotas, puedes solucionarlas con sudo apt -f install, que intentará descargar e instalar los paquetes faltantes. Es buena idea verificar después que los archivos se han instalado en las rutas previstas (por ejemplo, comprobando si el script está en /usr/bin o si las fuentes aparecen en el directorio correspondiente y son reconocidas por el sistema).

Para ver de nuevo los detalles del paquete una vez instalado o simplemente revisar su contenido, también tienes disponible:


dpkg --info nombre-del-paquete.deb


Y si quieres desinstalarlo, bastaría con usar:


sudo dpkg -r nombre-del-paquete


Si has definido correctamente un script postrm, en esta fase se ejecutarán las tareas de limpieza que hayas programado, eliminando directorios o ficheros residuales para dejar el sistema lo más limpio posible.

Compilar desde fuentes y reconstruir paquetes avanzados

Más allá de crear paquetes sencillos para scripts o recursos estáticos, en entornos más avanzados es frecuente recompilar paquetes existentes desde su código fuente. Esto puede ser necesario cuando necesitas una versión más reciente de un programa que la que trae tu distribución o cuando quieres cambiar las opciones de compilación por defecto.

A este proceso de compilar una versión más nueva de un paquete para que funcione en una distribución estable se le suele llamar retroadaptación o “backporting”. Lo típico es tomar el código fuente de una versión de Debian más moderna (por ejemplo, Testing o Unstable), adaptarlo y reconstruir el .deb para que sea compatible con tu sistema Stable.

Para descargar el código fuente de un paquete que ya existe en los repositorios, puedes usar:


apt source nombre-del-paquete


Por ejemplo, con samba:


apt source samba


Este comando se encarga de descargar los archivos fuente (normalmente un .dsc de control y uno o varios archivos comprimidos .tar.gz, .tar.xz, etc.), verificar su integridad y extraerlos en un directorio cuyo nombre combina el paquete y la versión, por ejemplo samba-4.13.13+dfsg.

Si tienes directamente la URL del archivo .dsc en un espejo de Debian o en la web del mantenedor, otra opción conveniente es usar dget (del paquete devscripts), que descarga el .dsc, los archivos asociados, verifica firmas mediante dscverify y extrae el paquete fuente, dejando todo listo para trabajar.

Modificar reglas de compilación y dependencias

Cuando lo que necesitas es cambiar opciones de compilación, tendrás que editar principalmente el archivo debian/rules, que controla las fases de construcción del paquete. En los casos más simples, verás llamadas claras a ./configure ..., make ..., cmake ... o similares, y bastará con ajustar las opciones para adaptarlas a tus necesidades.

En paquetes que usan el estilo moderno basado en debhelper (con el comando dh), estas llamadas pueden estar más escondidas. En ese caso, es posible que necesites crear overrides específicos para dh_auto_configure o dh_auto_build, de forma que se ejecuten tus parámetros extra durante la configuración o la compilación.

Otro archivo clave es debian/control (ojo, distinto del DEBIAN/control de un .deb ya construido), que describe los paquetes binarios que se generarán a partir del código fuente y, sobre todo, sus dependencias de compilación mediante el campo Build-Depends.

Este campo suele incluir versiones muy concretas de dependencias, pensadas para asegurar que en los servidores de construcción automáticos (autobuilders) siempre se usen las versiones esperadas de las bibliotecas. Sin embargo, cuando haces una retroadaptación a mano, puede que esas versiones no existan en tu distribución estable.

En esos casos, puedes considerar relajar algunas dependencias demasiado estrictas, siempre que tengas claro que el software puede compilar correctamente con versiones algo más antiguas. Conviene leer archivos como INSTALL o la documentación del proyecto para identificar qué librerías son realmente imprescindibles y qué versiones mínimas requieren.

A veces, para sacar adelante un backport, tendrás que ir retroadaptando también paquetes mencionados en Build-Depends que no estén disponibles en tu sistema, lo que puede convertirse en un proceso recursivo y bastante complejo si no tienes cuidado. Por eso se recomienda mantener al mínimo este tipo de cadenas de dependencias cuando sea posible.

Construir el paquete binario desde las fuentes

Una vez hayas aplicado los cambios necesarios en los archivos de empaquetado (por ejemplo en debian/rules y debian/control), llega el momento de generar de nuevo el paquete binario .deb. Para ello se utiliza principalmente el comando dpkg-buildpackage, que orquesta todo el proceso de compilación y empaquetado siguiendo las normas de Debian.

Es habitual utilizar opciones para evitar que se firmen automáticamente los archivos de control generados, como el .dsc y el .changes. Por ejemplo, las opciones -us y -uc sirven para indicar que no se firme el paquete fuente ni los cambios, algo razonable si solo estás haciendo pruebas locales.

Muchos desarrolladores prefieren usar una herramienta de más alto nivel, como debuild (también incluida en devscripts), que internamente llama a dpkg-buildpackage y además ejecuta una batería de comprobaciones extra sobre los paquetes generados, verificando si cumplen la política de Debian y limpiando variables de entorno que pudieran interferir con la compilación.

El resultado de este proceso será uno o varios archivos .deb listos para instalar en tu sistema, como harías con cualquier otro paquete. La gracia de este enfoque es que te permite adaptar programas complejos a tus necesidades particulares o traer versiones más nuevas a distribuciones estables sin tener que recurrir a repositorios externos potencialmente menos fiables.

Dominando desde la estructura mínima con DEBIAN/control y unos cuantos scripts básicos hasta las técnicas más avanzadas de recompilación desde fuentes y gestión de dependencias, tienes a tu alcance todo lo necesario para construir y mantener tus propios paquetes .deb, ya sea para scripts caseros, colecciones de fondos o aplicaciones completas, con un nivel de integración en el sistema idéntico al de cualquier paquete oficial.