Cómo crear un paquete tarball de código paso a paso

Si trabajas con Linux tarde o temprano vas a cruzarte con un tarball de código: ese típico archivo .tar, .tar.gz o .tar.bz2 que contiene el proyecto completo listo para compilar o empaquetar. A primera vista puede imponer un poco, pero en cuanto entiendes cómo se crea y cómo se usa, pasa a ser una herramienta básica de tu día a día.

En esta guía vas a ver cómo crear un paquete tarball de código paso a paso, cómo comprimir y descomprimir con tar, cómo preparar un proyecto para ser distribuido como código fuente y, además, cómo llevar ese tarball un poco más lejos empaquetándolo como .deb, .rpm o incluso en formatos universales como Snap, Flatpak o AppImage. Todo explicado con detalle, pero con un lenguaje terrenal, para que puedas ponerlo en práctica sin miedo.

Qué es exactamente un tarball y por qué se usa tanto

Un tarball no es más que un archivo generado con la herramienta tar que agrupa muchos ficheros y directorios en uno solo. Originalmente “tar” venía de Tape Archive, porque se usaba para volcar datos a cintas, pero hoy se utiliza sobre todo para empaquetar código fuente y hacer copias de seguridad.

Cuando ves extensiones como .tar, .tar.gz, .tgz o .tar.bz2, en realidad estás viendo un archivo tar más una capa de compresión. El proceso típico es: primero se agrupan todos los archivos con tar, y después ese tar se comprime con gzip (.gz), bzip2 (.bz2) o similares para reducir el tamaño.

En el ecosistema GNU/Linux se usan tarballs para distribuir el código fuente original de los programas, para mover grandes árboles de directorios entre servidores, para hacer backups de webs o datos y para compartir proyectos de forma independiente de la distribución (no dependen de .deb, .rpm, etc.). Por eso son tan universales.

Un punto clave es que tar respeta permisos, propietarios y estructura de directorios, algo fundamental cuando empaquetas código o configuraciones que deben instalarse tal cual en otra máquina.

Comandos básicos con tar: crear, listar y extraer

El comando tar es uno de los más usados en Linux y, pese a tener muchas opciones, en el día a día con que recuerdes unas pocas lo tienes casi todo resuelto. La sintaxis base siempre sigue el mismo patrón:

tar archivo.tar rutas…

Entre las opciones más habituales para trabajar con tarballs de código están c, x, t, v, f, z y j. Cada combinación te permite crear, examinar o extraer diferentes tipos de archivo .tar, .tar.gz o .tar.bz2 sin complicarte demasiado.

Crear un archivo .tar sencillo

Para empaquetar código sin compresión, por ejemplo el directorio ~/proyectos/miprog-1.0, puedes ejecutar:

tar -cvf miprog-1.0.tar ~/proyectos/miprog-1.0

Las opciones que estás usando en este comando de tar son muy típicas: c para crear un nuevo archivo, v para ver en pantalla qué se está añadiendo (modo “verboso”) y f para indicar el nombre del archivo de salida (miprog-1.0.tar). El resultado es un tarball sin compresión que ya podrías distribuir o guardar como copia de seguridad.

Crear un tarball comprimido .tar.gz o .tgz

En la práctica casi siempre interesa que el tarball de código ocupe menos. Para eso se usa gzip con la opción -z de tar, de forma que ambos procesos (tar + compresión) se hagan en un solo comando:

tar -cvzf miprog-1.0.tar.gz ~/proyectos/miprog-1.0

Aquí la opción z indica que se use gzip como compresor. El archivo generado puede llamarse .tar.gz o .tgz, porque a efectos prácticos son equivalentes. El contenido sigue siendo el mismo, pero comprimido, ideal para subirlo a una web de descargas, adjuntarlo a un correo o publicarlo como “release” en un repositorio.

Crear un tarball comprimido .tar.bz2

Si necesitas una compresión más agresiva (archivos algo más pequeños a costa de tardar un poco más al comprimir y descomprimir), puedes usar bzip2 con la opción -j:

tar -cvjf miprog-1.0.tar.bz2 ~/proyectos/miprog-1.0

La bandera j indica a tar que use bzip2. Es habitual encontrar variantes de nombre como .tar.tbz o .tar.tb2, pero la idea es idéntica: un tar comprimido con bzip2 y listo para distribuir.

Listar el contenido de un tarball

Antes de extraer o tocar nada puedes querer ver qué hay dentro del tarball. Para eso está la opción t (de table of contents):

tar -tvf miprog-1.0.tar

Con este comando obtendrás un listado detallado con rutas de archivos, permisos y marcas de tiempo. El mismo patrón sirve para .tar.gz y .tar.bz2, ya que tar detecta la compresión a partir de las opciones z o j:

tar -tvf miprog-1.0.tar.gz
tar -tvf miprog-1.0.tar.bz2

Extraer archivos de un tarball

Para descomprimir y extraer el contenido en el directorio actual solo necesitas cambiar la c por la x, manteniendo el resto igual:

tar -xvf miprog-1.0.tar

Si quieres indicarle un directorio concreto donde dejar los ficheros, añade la opción -C seguida de la ruta destino. De esta forma puedes mantener ordenadas tus fuentes o tus copias de seguridad:

tar -xvf miprog-1.0.tar -C /home/usuario/src/

Lo mismo vale para tarballs comprimidos con gzip o bzip2, simplemente añadiendo la opción de compresión correspondiente, como por ejemplo tar -xvzf archivo.tar.gz o tar -xvjf archivo.tar.bz2.

Extraer archivos concretos y usar comodines

Una de las ventajas de tar es que puedes extraer solo algunos ficheros en vez de descomprimirlo todo. Por ejemplo, si dentro de sampleArchive.tar hay un script llamado example.sh que quieres recuperar:

tar -xvf sampleArchive.tar example.sh

Este mismo enfoque vale para tarballs comprimidos, añadiendo z o j según toque. También puedes usar la opción –wildcards para extraer solo archivos que cumplan un patrón, algo muy práctico para cosas como sacar únicamente las imágenes .jpg:

tar -xvf sampleArchive.tar –wildcards ‘*.jpg’

En el caso de .tar.gz o .tar.bz2 el comando sería similar cambiando a -zxvf o -jxvf para respetar el método de compresión empleado en el archivo original.

Crear un tarball de código fuente desde cero

Más allá de comprimir carpetas sueltas, el uso clásico del tarball en el mundo Unix es distribuir el código fuente de un programa. La idea es muy sencilla: el autor prepara un directorio limpio con el proyecto, lo empaqueta como tar.gz o tar.bz2 y lo publica. Los usuarios descargan ese tarball, lo extraen y lo compilan localmente.

En muchos casos ese árbol de código tiene un nombre del estilo programa-versión, por ejemplo hello-sh-1.0, de modo que el tarball resultante se llame hello-sh-1.0.tar.gz y, al descomprimirlo, se genere exactamente ese directorio con todo lo necesario dentro.

Un ejemplo muy típico para practicar consiste en crear un mini proyecto con un script sencillo, darle permisos de ejecución y empaquetarlo después. Por ejemplo:

$ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
$ cat > hello <<EOF
#!/bin/sh
# (C) 2011 Foo Bar, GPL2+
.echo «Hello!»
EOF
$ chmod 755 hello
$ cd ..
$ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

Con este procedimiento has generado un tarball trivial con código fuente que luego podrías desempaquetar en cualquier distro Unix-like y ejecutar el script sin más historias.

Descargar, desempaquetar y preparar el código fuente

Lo normal hoy en día es que el autor de un programa libre publique su código en forma de tar.gz o tar.bz2 en su web o en plataformas tipo GitHub. Esos ficheros contienen el árbol de fuentes, documentación (README, INSTALL, etc.) y, muchas veces, los ficheros necesarios para generar Makefiles y scripts de compilación.

Si el proyecto no viene como tarball sino desde un control de versiones (Git, Subversion, CVS…), entonces tendrás que clonar el repositorio con git clone, svn co o cvs co y, después, empaquetar tú mismo ese directorio con tar, preferiblemente usando la opción –exclude-vcs para no meter los metadatos del sistema de control de versiones:

tar -cvzf proyecto-1.0.tar.gz –exclude-vcs proyecto-1.0

En ocasiones el archivo de origen viene comprimido en otros formatos como .zip o .Z. En ese caso lo descomprimes con las herramientas adecuadas y, si quieres seguir el estándar clásico de distribución en GNU/Linux, vuelves a empaquetarlo como tarball (tar.gz o tar.bz2) manteniendo la estructura programa-versión.

Instalar herramientas de compilación y leer la documentación

Antes de ponerte a compilar nada desde un tarball, conviene que tu sistema tenga las herramientas básicas de desarrollo. En Debian, Ubuntu y derivados esto suele ser tan simple como instalar el metapaquete build-essential:

sudo apt install build-essential

En otras distribuciones cambian los nombres pero la idea es la misma: en Fedora/Red Hat puedes tirar de sudo dnf groupinstall «Development Tools», y en Arch Linux usar sudo pacman -S base-devel. Lo importante es que tengas compilador (gcc, g++), make y cabeceras estándar.

Una vez descomprimido el tarball, lo primero es entrar en el directorio del proyecto y leer muy atentamente los ficheros README e INSTALL, porque ahí suele explicarse el método de compilación, las dependencias y cualquier peculiaridad. Para eso puedes usar less, cat o tu editor preferido.

Compilar código fuente desde un tarball: método clásico

La mayoría de proyectos sencillos que se distribuyen en tarball incluyen un Makefile (puedes aprender a crear y dominar Makefile) o un sistema de compilación basado en Autotools. En esos casos el flujo típico consiste en tres pasos: configurar, compilar e instalar, con algunos matices según el proyecto.

En muchos casos basta con que, tras descomprimir el tarball, ejecutes en el directorio raíz del código algo como ./configure && make && sudo make install. Pero por debajo hay bastantes detalles interesantes que merece la pena conocer para no ir a ciegas.

Autotools: configure, Makefile y compañía

Muchos programas libres utilizan las Autotools de GNU (Autoconf, Automake, Libtool, gettext…) para generar Makefiles portables a varias plataformas. Si ves archivos como configure.ac, Makefile.am o Makefile.in en el árbol de fuentes, es casi seguro que el proyecto está montado sobre este sistema.

El autor suele ejecutar en su entorno autoreconf -i -f para generar, a partir de esos ficheros fuente, el script configure y los Makefile.in correspondientes. Después, tú en tu máquina llamarás a ./configure, que creará los Makefile definitivos adaptados a tu sistema (detectando librerías, rutas, compilador, etc.).

El flujo simplificado sería algo así: a partir de configure.ac y Makefile.am se construyen configure y Makefile.in, y de ahí, al ejecutar ./configure, se generan Makefile y config.h. Finalmente, un simple make compila el binario. Si necesitas ajustar directorios de instalación puedes pasar opciones al script configure, por ejemplo ./configure –prefix=/usr para cambiar el prefijo de instalación estándar.

Compilación con CMake como alternativa moderna

Otro sistema de construcción muy extendido hoy es CMake. Lo reconocerás por la presencia del archivo CMakeLists.txt en la raíz del proyecto. El patrón para compilar desde un tarball suele consistir en crear un directorio build aparte, generar ahí la configuración y compilar dentro:

mkdir build
cd build
cmake ..
make
sudo make install

Este enfoque mantiene el árbol de fuentes más limpio y permite generar proyectos para distintas plataformas o IDEs usando los mismos CMakeLists.txt. La lógica, no obstante, sigue siendo la misma que con Autotools: configurar, compilar e instalar.

Resolver errores de dependencias al configurar

Es bastante habitual que la primera pasada de ./configure falle porque falta alguna librería, encabezado o dependencia de desarrollo. El script suele mostrar un mensaje claro del estilo “no se ha encontrado libejemplo” o “cannot find header xyz.h”.

En muchas distribuciones las librerías se empaquetan en tres variantes: binario, biblioteca y biblioteca de desarrollo. Siguiendo el patrón del ejemplo, podrías tener paquetes llamados ejemplo, libejemplo y libejemplo-dev. Para compilar desde el tarball normalmente necesitas la variante -dev (incluye cabeceras y archivos necesarios para enlazar), así que si configure protesta por libejemplo, la solución real suele ser instalar libejemplo-dev y reintentar.

Es posible que, tras instalar un -dev, vuelvas a ejecutar configure y se queje ahora de otra biblioteca distinta. No pasa nada: es un proceso de ensayo y error hasta que cumples todas las dependencias. Una vez superas esa fase, configure termina con éxito y puedes lanzarte a compilar.

Compilar con make e instalar con make install

Cuando el paso de configuración ha ido bien, ya puedes ejecutar make para compilar el proyecto. Dependiendo del tamaño del programa y de la potencia de tu máquina, este proceso puede durar desde unos segundos hasta varios minutos. Verás desfilar en la terminal las líneas de compilación y enlace que se van ejecutando.

Si todo va correctamente y no aparecen errores de compilación, solo queda instalar el resultado en el sistema con sudo make install. Por convención, muchos proyectos se instalan bajo /usr/local (binarios en /usr/local/bin, librerías en /usr/local/lib, configuraciones en /usr/local/etc…), de manera que no se mezclan con los paquetes propios de la distribución.

Algunos proyectos implementan también el objetivo make uninstall, que permite revertir la instalación y borrar los ficheros que se copiaron con make install. No todos lo traen, pero si en la documentación aparece, es una manera relativamente cómoda de desinstalar lo que has compilado desde el tarball.

Cuándo y cómo crear un tarball orientado a empaquetar en Debian

En el mundo Debian y derivados, el tarball de código original se suele denominar nombre_versión.orig.tar.gz. La idea es separar claramente el origen “upstream” del código de las modificaciones específicas de Debian (parches, ficheros de control, scripts de postinstalación, etc.) que se añaden en el directorio debian del paquete fuente.

Si el desarrollador original ha llamado a su tarball gentoo-0.9.12.tar.gz, por ejemplo, como mantenedor Debian puedes renombrarlo a gentoo_0.9.12.orig.tar.gz y trabajar a partir de ahí. Sobre ese origen añadirás el subdirectorio debian con todos los ficheros necesarios para construir los .deb.

La herramienta dh_make facilita bastante esta tarea: a partir de gentoo-0.9.12.tar.gz descomprime las fuentes, genera el tarball .orig adecuado y crea plantillas en debian/ que luego puedes ir ajustando. Tras ejecutarla verás que en tu directorio de trabajo coexisten el original renombrado y el árbol de fuentes preparado para empaquetar.

Nombrar bien el paquete y la versión en tarballs y paquetes

Cuando distribuyes código fuente en forma de tarball es fundamental que el nombre del archivo y el directorio interno sigan una convención coherente. En el ecosistema Debian, por ejemplo, se recomienda que el nombre del paquete use solo minúsculas, dígitos, signos + y – y puntos, con una longitud razonable y empezando siempre por un carácter alfanumérico.

El número de versión, por su parte, debería tener solo caracteres alfanuméricos, +, ~ y puntos, empezando siempre por un dígito. Esto facilita que herramientas como dpkg comparen versiones correctamente. Si el autor del programa usa cadenas raras (fechas con texto, hashes de Git, etc.) puedes guardar esa información en el changelog de Debian, pero conviene que el campo “upstream version” del tarball se mantenga limpio y ordenado.

En casos de versiones previas o candidatas, se suele insertar un ~ (tilde) para que dpkg interprete bien el orden. Por ejemplo, si tienes un pre-lanzamiento gentoo-0.9.12-ReleaseCandidate-99.tar.gz, puedes renombrarlo a gentoo-0.9.12~rc99.tar.gz, de forma que 0.9.12 sea considerado superior a 0.9.12~rc99 cuando llegue la versión final.

De tarball a paquete binario: empaquetar como .deb

Un tarball de código es solo el primer paso si tu objetivo es distribuir el programa como paquete instalable .deb (ver instaladores de paquetes de software más populares). A partir del tar.gz original puedes crear la estructura necesaria para generar un .deb, añadir el binario compilado y la metainformación, y construir el paquete con dpkg-deb.

Por dentro, un archivo .deb contiene básicamente tres piezas: debian-binary (un archivo de texto mínimo con la versión del formato), control.tar.gz (metadatos y scripts de control) y data.tar.gz (los binarios y ficheros que se instalarán). Con la utilidad ar puedes inspeccionar un .deb y ver exactamente estos componentes.

Para empaquetar algo muy sencillo, como un “hola mundo” en C, podrías compilar primero el binario a partir del código fuente que venía en el tarball y luego montar la estructura de directorios del .deb a mano. Crearías un directorio hola/, dentro un subdirectorio DEBIAN con el archivo control y, en la ruta adecuada (por ejemplo hola/usr/bin/), copiarías el ejecutable. Después bastaría con llamar a dpkg-deb –build hola para generar hola.deb.

De tarball a paquete RPM y otros formatos

Algo muy similar ocurre en el mundo Red Hat con los paquetes RPM. El código fuente suele distribuirse también en tarballs, y a partir de ahí se generan los SRPM (paquetes fuente RPM) que contienen tanto el tarball original como uno o varios parches y el fichero .spec que describe cómo compilar e instalar el programa.

En este caso, la estructura de directorios de trabajo incluye rutas como RPMS, SRPMS, SOURCES, SPECS…. El tarball original va a SOURCES, el .spec a SPECS y, desde ahí, puedes usar rpmbuild para generar el .rpm binario y, si lo deseas, el .src.rpm. El .spec recoge datos como el nombre del paquete, la versión, las dependencias, los comandos de construcción y la lista de ficheros que deben acabar en el sistema.

El resultado final es muy parecido a un .deb: un paquete binario que el usuario puede instalar con su gestor de paquetes habitual, pero cuya raíz suele ser un tarball de código fuente organizado y bien versionado.

Crear tarballs y empaquetar en formatos universales

En los últimos años han aparecido formatos como Snap, Flatpak y AppImage que pretenden ofrecer paquetes “universales” para Linux, evitando buena parte de la fragmentación entre distros. Aunque cada uno tiene su mecánica, todos ellos pueden tomar como punto de partida un árbol de código que podrías distribuir igualmente en forma de tarball.

En Snap, por ejemplo, defines en el archivo snapcraft.yaml cómo se construye tu aplicación: nombre, versión, fuente (que puede ser una URL a un tarball remoto), plugins de construcción (autotools, cmake, etc.) y el comando final a ejecutar. Snapcraft se encargará de descargar el tarball, compilarlo y empaquetarlo junto con sus dependencias.

Flatpak funciona con un manifiesto JSON o YAML que describe el runtime, el SDK y los módulos a construir, indicando también la fuente (puede ser un archivo local o un tarball remoto). De nuevo, el tarball es el contenedor natural del código fuente que se integrará después en el paquete universal.

En AppImage, aunque muchas veces se parte de binarios ya compilados, también puedes llegar desde un árbol de código clásico: compilas desde el tarball, generas la estructura AppDir y finalmente creas la imagen autoejecutable que el usuario puede lanzar sin instalación propiamente dicha.

Tarballs, compresión directa y otras utilidades prácticas

Además de empaquetar código, tar se utiliza muchísimo para comprimir y descomprimir datos genéricos: directorios de configuración, carpetas personales, backups puntuales, etc. En sistemas tipo Unix, incluidas muchas versiones de Android y macOS, tar suele venir de serie y ofrece una relación de compresión muy razonable, cercana al 50% en muchos casos, con una velocidad de operación bastante alta.

Pero ojo, hay matices: herramientas como gzip o bzip2 solo comprimen archivos, no directorios. Cuando lanzas un tar -czf o tar -cjf, en realidad tar se ocupa primero de agrupar directorios y luego pasa el resultado a gzip o bzip2. Por eso es tan práctico usar tar como “frontal” de estas utilidades.

Si quieres verificar rápidamente el tamaño que tendrá un tarball o medir el impacto de la compresión, puedes encadenar tar con wc -c para contar bytes, usando un guion como salida estándar. Por ejemplo:

tar -czf – sampleArchive.tar | wc -c

Con este truco es fácil hacerse una idea de cuánto peso estás ahorrando al empaquetar un directorio concreto, algo muy útil cuando preparas distribuciones de código o copias de seguridad que vas a mover por la red.

Como ves, dominar el uso de tarballs para empaquetar y distribuir código paso a paso te abre muchas puertas: desde crear simples copias comprimidas de tus proyectos hasta preparar fuentes limpias para empaquetar en .deb, .rpm o formatos universales; todo ello manteniendo permisos, estructura de directorios y buenas prácticas de versionado que harán tu vida (y la de quienes usen tu software) mucho más sencilla.