Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as
Testing or even
Unstable — so that this new package works in their
Stable distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information.
15.1.1. Obtención de las fuentes
Rebuilding a Debian package starts with getting its source code. The easiest way is to use the
apt-get source source-package-name
command. This command requires a
deb-src
line in the
/etc/apt/sources.list
file, and up-to-date index files (i.e.
apt-get update
). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see
Sección 6.1, “Contenido del archivo sources.list
”). Note however, that you will be downloading the source packages from the Debian version mentioned in the
deb-src
line. If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions
*.dsc
— for
Debian Source Control —
*.tar.comp
, and sometimes
*.diff.gz
or
*.debian.tar.comp
—
comp taking one value among
gz
,
bz2
or
xz
depending on the compression tool in use), then run the
dpkg-source -x file.dsc
command. If the
*.dsc
file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the
dget URL
command. This command (which can be found in the
devscripts package) fetches the
*.dsc
file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it extracts the source package (unless the
-d
or
--download-only
option is used).
15.1.2. Realización de cambios
Ahora tiene las fuentes del paquete disponibles en un directorio cuyo nombre coincide con el paquete fuente y su versión (por ejemplo: samba-4.1.17+dfsg); allí es donde trabajaremos en nuestros cambios locales.
Lo primero que debemos hacer es cambiar el número de versión del paquete para que podamos distinguir el paquete recompilado del paquete original que provee Debian. Si asumimos que la versión actual es 2:4.1.17+dfsg-2
podemos crear la versión 2:4.1.16+dfsg2falcot1
, que indica claramente el origen del paquete. Esto además hace que el número de versión del paquete sea mayor al del que provee Debian para que el paquete se instalará fácilmente como una actualización al paquete original. La mejor forma de realizar dicho cambio es con el programa dch
(por cambios Debian: «Debian CHangelog») del paquete devscripts ejecutando algo similar a dch --local falcot1
. Esto invoca un editor de texto (sensible-editor
— este debería ser tu editor favorito si es mencionado en las variables de entorno VISUAL
o EDITOR
o el editor predeterminado de lo contrario) que nos permitirá documentar las diferencias introducidas en esta recompilación. Este editor nos mostrará que dch
realmente cambió el archivo debian/changelog
.
When a change in build options is required, the changes need to be made in debian/rules
, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …
) or the actual build ($(MAKE) …
or make …
) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh
, you might need to add an override for the dh_auto_configure
or dh_auto_build
commands (see their respective manual pages for explanations on how to achieve this).
Dependiendo de los cambios locales a los paquetes, también podría necesitar actualizar el archivo debian/control
, que contiene una descripción de los paquetes generados. En particular, este paquete contiene líneas Build-Depends
que controlan la lista de dependencias que se deben cumplir en el momento de compilar un paquete. Éstas líneas generalmente hacen referencia a las versiones de los paquetes que se encuentran en la distribución de la que proveen los paquetes fuente pero que pueden no estar disponibles en la distribución en la que estamos recompilando. No hay una forma automatizada para determinar si una dependencia es real o sólo está presente para garantizar que sólo se intente compilar con la última versión de una biblioteca — esta es la única forma de forzar que autobuilder utilice una versión específica de un paquete durante su compilación, por lo que los desarrolladores Debian frecuentemente utilizan dependencias de compilación con versiones estrictas.
Si está seguro que estas dependencias de compilación son muy estrictas, siéntase libre de relajarlas localmente. Lea los archivos que documentan la forma estándar de compilar el software — generalmente estos archivos son llamados INSTALL
— le ayudarán a encontrar las dependencias adecuadas. Idealmente, podrá satisfacer todas las dependencias en la distribución que utilice para recompilar; de lo contrario, comienza un proceso recursivo en el que debemos retroadaptar los paquetes mencionados en el campo Build-Depends
antes de poder finalizar con el paquete deseado. Algunos paquetes pueden no necesitar ser retroadaptados y puede instalarlos tal cual durante el proceso de compilación (un ejemplo notable es debhelper). Sepa que el proceso de retroadaptación puede volverse muy complejo rápidamente si no tiene cuidado. Por lo tanto, debe mantener al mínimo las retroadaptaciones siempre que sea posible.
15.1.3. Inicio de la recompilación
Cuando aplicamos los cambios necesarios a las fuentes, podemos comenzar la generación del paquete binario (archivo .deb
). El programa dpkg-buildpackage
gestiona todo el proceso.
Ejemplo 15.1. Recompilación del paquete
$
dpkg-buildpackage -us -uc
[...]
El programa anterior puede fallar si no se actualizaron los campos Build-Depends
o si no están instalados los paquetes relacionados. En tal caso, es posible evitar este chequeo con la opción -d
de dpkg-buildpackage
. Sin embargo, al ignorar explícitamente estas dependencias corre el riesgo de que el proceso de compilación falle en una etapa posterior. Lo que es peor, el paquete puede parecer compilar correctamente pero no ejecutar correctamente: algunos programas desactivan automáticamente algunas de sus funcionalidades cuando una biblioteca necesaria no está disponible al momento de compilarlo.
La mayoría de las veces, los desarrolladores Debian utilizan un programa de alto nivel como debuild
; éste ejecuta dpkg-buildpackage
normalmente, pero también agrega una invocación de un programa que ejecuta muchos chequeos para validar el paquete generado según la normativa Debian. Este script también limpia el entorno para que las variables de entorno locales no «contaminen» la compilación del paquete. El programa debuild
es una de las herramientas de devscripts, que comparte un poco de consistencia y configuración para facilitar la tarea del desarrollador.