Tabla de contenidos
Ahora deberíamos estar preparados para construir el paquete.
Para realizar correctamente la (re)compilación completa de un paquete, debes asegurarte que tienes instalados:
el paquete build-essential
.
los paquetes listados en el campo Build-Depends
del
archivo «control» (Sección 4.1, “El archivo control
” ), y
los paquetes listados en el campo Build-Depends-indep
(también del archivo «control», Sección 4.1, “El archivo control
”).
Después ejecuta la siguiente orden en el directorio raíz del código fuente del programa:
$ dpkg-buildpackage -us -uc
Esto hará todo lo necesario para construir los paquetes binarios y de fuentes para ti. Para ello:
limpia el árbol del código fuente («debian/rules clean
»)
construye el paquete de código («dpkg-source -b
»)
construye el programa («debian/rules build
»)
construye el paquete binario (fakeroot debian/rules
binary
)
genera el fichero .dsc
genera el fichero .changes
, utilizando
dpkg-genchanges
Si el resultado de la compilación es satisfactorio, firma los ficheros de
extensión .dsc
y .changes
con tu
clave privada GPG utilizando la orden debsign. Deberás
escribir la contraseña de tu clave dos veces. [64]
Para los paquetes no nativos Debian, p.ej, gentoo
, podrás ver los siguientes archivos en el
directorio padre (~/gentoo
) después de construir el
paquete:
gentoo_0.9.12.orig.tar.gz
Este es el código fuente original comprimido, simplemente se ha renombrado
para seguir los estándares de Debian. Debe tenerse en cuenta que fue
generado usando la opción «-f» de dh_make -f
../gentoo-0.9.12.tar.gz
ejecutada en el inicio.
gentoo_0.9.12-1.dsc
Este es un sumario de los contenidos del código fuente. Este fichero se
genera a partir del fichero de control
y se usa cuando
se descomprimen las fuentes con dpkg-source(1).
gentoo_0.9.12-1.debian.tar.gz
Este fichero comprimido contiene el directorio debian
completo. Todas las modificaciones de las fuentes originales se conservan
en los archivos de parches quilt en el directorio
debian/patches
.
Si alguien quiere volver a construir tu paquete desde cero, puede hacerlo
fácilmente usando los tres ficheros de arriba. El proceso de extracción es
trivial: sólo se debe copiar los tres ficheros en algún lado y ejecutar
dpkg-source -x gentoo_0.9.12-1.dsc
[65].
gentoo_0.9.12-1_i386.deb
Este es el paquete binario completo. Puedes usar dpkg para instalar o eliminar tanto este paquete como cualquier otro.
gentoo_0.9.12-1_i386.changes
Este fichero describe todos los cambios hechos en la revisión actual del
paquete, y lo utilizan los programas de mantenimiento del archivo FTP de
Debian para instalar los paquetes binarios y fuentes. Se genera
parcialmente a partir del fichero changelog
y el
fichero .dsc
.
Mientras sigues trabajando en el paquete, éste cambiará su comportamiento y se le añadirán nuevas funciones. Las personas que descarguen tu paquete pueden leer este fichero y ver qué ha cambiado. Los programas de mantenimiento del archivo de Debian, también enviarán el contenido de este fichero a la lista de correo debian-changes-announce@lists.debian.org.
Sera necesario firmar los ficheros gentoo_0.9.12-1.dsc
y gentoo_0.9.12-1_i386.changes
utilizando la orden
debsign con la clave privada GPG almacenada en el
directorio ~/.gnupg/
, antes de subirlos al archivo FTP
de Debian. La firma GPG proporciona la prueba de que estos ficheros son
realmente tuyos usando tu clave pública GPG.
La orden debsign puede ejecutarse para firmar utilizando
la ID de tu clave GPG privada (útil para patrocinar paquetes)
,especificándola en el siguiente ~/.devscripts
como
sigue:
DEBSIGN_KEYID=Tu_GPG_keyID
Las largas listas de números en los ficheros .dsc
y
.changes
son las sumas MD5/SHA1/SHA256 de los ficheros
incluidos en el paquete. Las personas que descarguen estos ficheros pueden
comprobarlos con md5sum(1), sha1sum(1) o sha256sum(1) y si los números no coinciden,
sabrán que el fichero está corrupto o ha sido modificado.
Debian mantiene diversas adaptaciones «ports» con la red de servidores de compilación automática que ejecuta demonios buildd en ordenadores con diferentes arquitecturas. Aunque no deberás hacer todo esto tú mismo, debes conocer el proceso al que se verá sometido tu paquete. Veamos cómo se procesa el paquete para compilarlo en diversas arquitecturas [66].
Los paquetes del tipo Architecture: any
, son construidos
por el sistema de compilación automática. El sistema garantiza la
instalación de:
el paquete build-essential
, y
los paquetes listados en el campo Build-Depends
(véase
Sección 4.1, “El archivo control
” ).
A continuación se ejecuta la siguiente orden en el directorio de las fuentes:
$ dpkg-buildpackage -B
De esta manera, se ejecuta todo lo necesario para construir el paquete binario dependiente de la arquitectura en cada arquitectura. Hace lo siguiente:
limpia el árbol del código fuente («debian/rules clean
»)
construye el programa («debian/rules build
»)
construye el paquete binario para la arquitectura (fakeroot
debian/rules binary-arch
)
firma el fichero fuente .dsc
, usando
gpg
genera y firma el fichero de envío .changes
, usando
dpkg-genchanges y gpg
Esta es la razón por la que el paquete estará disponible para otras arquitecturas.
Aunque es necesario instalar los paquetes listados en el campo
Build-Depends-indep
para el empaquetamiento normal (véase
Sección 6.1, “(Re)construcción completa” ), el sistema automático de construcción no
lo requiere puesto que solo construye paquetes binarios dependientes de la
arquitectura [67]. Estas diferencias entre
el empaquetamiento normal y el automático determinan si los paquetes
requeridos para la compilación se deben listar en el campo
Build-Depends
o bien en el campo
Build-Depends-indep
del archivo
debian/control
(véase Sección 4.1, “El archivo control
” ).
Puedes automatizar aún más el proceso de construcción de paquetes de la orden dpkg-buildpackage con la orden debuild. Véase debuild(1).
La orden dbuild ejecuta a su vez la orden
lintian para comprobar el paquete Debian compilado. La
orden lintian puede configurarse con el siguiente
~/.devscripts
:
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i" DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
Por ejemplo, limpiar el código y reconstruir el paquete desde una cuenta de usuario es tan simple como:
$ debuild
Puedes eliminar los archivos generados en la compilación ejecutando:
$ debuild clean
El paquete pbuilder
es muy útil para
conseguir un entorno de compilación limpio (chroot) donde
verificar las dependencias de compilación [68]. Esto asegura una construcción limpia desde el código en los
auto-compiladores de sid
para las distintas arquitecturas
y evita fallos de nivel de severidad serios del tipo FTBFS («Fail to Build
From Source», o «fallo al construir desde la fuente »), que son siempre de
categoría RC (fallos críticos o «release critical»). [69]
Para personalizar el funcionamiento del paquete pbuilder
haz lo siguiente:
permite que tu usuario del sistema tenga permiso de escritura en el
directorio /var/cache/pbuilder/result
.
crea un directorio, p.e.
,
con permiso de escritura para tu usuario. En este directorio pondrás los
guiones «hook»
/var/cache/pbuilder/hooks
establece los archivos ~/.pbuilderrc
o
/etc/pbuilderrc
con el siguiente contenido:
AUTO_DEBSIGN=${AUTO_DEBSIGN:-no}
HOOKDIR=/var/cache/pbuilder/hooks
Ahora puedes inicializar el sistema local pbuilder
chroot por primera
vez ejecutando:
$ sudo pbuilder create
Si ya dispones de un paquete fuente completo, ejecuta las siguientes órdenes
en el directorio donde tengas los archivos
,
nombre_del_paquete
.orig.tar.gz
y nombre_del_paquete
.debian.tar.gz
para actualizar el sistema local nombre_del_paquete
.dscpbuilder
chroot y, a
continuación, compilar el paquete binario en él:
$ sudo pbuilder --update
$ sudo pbuilder --build nombre_del_paquete
.dsc
Una vez finalizada la compilación, el paquete compilado estará en el
directorio /var/cache/pbuilder/result/
cuyo propietario
será tu usuario en lugar del usuario administrador.
Las firmas GPG en los archivos .dsc
y
.changes
se puede generar como sigue
$ cd /var/cache/pbuilder/result/
$ debsign nombre_del_paquete_versión_arquitectura
.changes
Si en lugar de iniciar la construcción del paquete a partir de un paquete ya
construido, dispones de un directorio con las fuentes originales
actualizadas, deberás ejecutar las siguientes órdenes desde el directorio de
las fuentes originales (y en el que deberá estar presente el directorio
debian
con todo su contenido):
$ sudo pbuilder --update $ pdebuild
Puedes «conectarte» al entorno chroot ejecutando la orden
pbuilder --login --save-after-login
y configurarlo para
adaptarlo a tus necesidades. Este entorno puede guardarse saliendo del
«shell» con ^D
(Control-D).
La última versión de la orden lintian puede ejecutarse
automáticamente en el entorno chroot
utilizando el guión
«hook» disponible en
y configurado como sigue [70]:
/var/cache/pbuilder/hooks
/B90lintian
#!/bin/sh set -e install_packages() { apt-get -y --force-yes install "$@" } install_packages lintian echo "+++ lintian output +++" su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder # use esta versión si quiere evitar que lintian pare la compilación #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder echo "+++ final del informe de lintian +++"
Debes tener un entorno sid
actualizado para construir
correctamente paquetes para sid
. En realidad, al versión
sid
puede contener errores que no hacen recomendable la
migración de tu sistema a esta versión. El paquete pbuilder
te ayuda a hacer frente a esta
situación.
Es posible que debas actualizar tu paquete stable
después
de distribuirlo para stable-proposed-updates
,
stable/updates
, etc [71]. En algunas ocasiones, «Yo trabajo con la versión
sid
» puede no ser una excusa para dejar de actualizar el
paquete. El paquete pbuilder
te
ayuda trabajar en entornos para todas las distribuciones derivadas Debian
para una arquitectura determinada.
Consulta http://www.netfort.gr.jp/~dancer/software/pbuilder.html, pdebuild(1), pbuilderrc(5), y pbuilder(8).
Si el autor original utiliza un sistema de gestión de versiones para el código [72] puedes considerar utilizarlo. Así se facilita la coordinación y la selección de los parches en las fuentes. Debian dispone de varios paquetes de guiones especializados en cada tipos de VCS:
git-buildpackage
: conjunto para la
compilación de paquetes en repositorios «Git».
svn-buildpackage
: programas de ayuda
para el mantenimiento de paquetes Debian con «Subversion».
cvs-buildpackage
: conjunto de
paquete de guiones Debian para estructuras de directorios CVS.
El uso de git-buildpackage
se está
convirtiendo en muy popular para los desarrolladores de Debian para el
mantenimiento de los paquetes Debian con el servidor Git en alioth.debian.org. [73] Este paquete ofrece muchas órdenes para
automatizar el mantenimiento de paquetes:
git-import-dsc(1): importa la versión anterior del paquete Debian al repositorio «Git».
git-import-orig(1): importa el nuevo fichero «tar» del autor al repositorio «Git».
git-dch(1): genera el fichero de cambios de Debian desde los mensajes de cambios de «Git».
git-buildpackage(1): compila los paquetes Debian del repositorio «Git».
git-pbuilder(1): compila los paquetes Debian del repositorio «Git» utilizando pbuilder/cowbuilder.
Estas órdenes utilizan 3 ramas en la gestión del proceso de empaquetado:
main
(principal) del árbol de directorios del paquete
Debian.
upstream
(autor) para el árbol de las fuentes del autor.
pristine-tar
por el fichero comprimido «.tar» del autor
generado por la opción --pristine-tar
.[74]
Puedes configurar git-buildpackage
con ~/.gbp.conf
. Lee gbp.conf(5). [75]
Con un paquete grande, puede que no quieras recompilar desde cero cada vez
que tocas un detalle en el fichero debian/rules
. Para
propósitos de prueba, puedes hacer un fichero .deb
sin
necesidad de recompilar las fuentes originales de esta forma[76]:
fakeroot debian/rules binary
O simplemente puedes comprobar si el paquete se compila con:
$ fakeroot debian/rules build
Una vez terminada la puesta a punto, recuerda reconstruir el paquete
siguiendo el procedimiento adecuado explicado anteriormente. Puede que no
seas capaz de enviar correctamente el paquete si intentas enviar los
archivos .deb
construidos de esta forma.
A continuación hay un breve resumen de cómo las órdenes de construcción de paquetes encajan jerárquicamente. Hay muchas maneras de hacer lo mismo.
debian/rules
= guión del desarrollador para la
construcción del paquete
dpkg-buildpackage = orden principal de las herramientas de compilación
debuild = dpkg-buildpackage + lintian (construcción con la configuración estándar de las variables de entorno)
pbuilder = núcleo de la herramienta de entorno «chroot» de Debian
pdebuild = pbuilder + dpkg-buildpackage (construcción en el entorno «chroot»"
cowbuilder = ejecución acelerada de pbuilder
git-pbuilder = la versión de sintaxis fácil para pdebuild (utilizado por gbp buildpackge)
gbp = gestor de los ficheros Debian del paquete en un repositorio «git»
gbp buildpackge = pbuilder + dpkg-buildpackage + gbp
Aunque el uso de las órdenes de nivel superior como gbp
buildpackge y pbuilder asegura el entorno
perfecto de construcción de paquetes, es esencial para comprender cómo
órdenes de menor nivel, tales como debian/rules
y
dpkg-buildpackage se ejecutan subordinadas.
[64] Esta clave GPG debe ser firmado por un desarrollador de Debian para conectarse a la red de confianza y debe registrarse en el anillo de claves de Debian. Esto permite que los paquetes sean aceptados en los repositorios de Debian. Consulta Cómo crear un clave GPG nueva y Wiki de Debian sobre la firma de claves.
[65] Puedes evitar la aplicación automática de las modificaciones por
dquilt en los paquetes con formato 3.0
(quilt)
al final de la extracción con la opción
--skip-patches
. También puedes deshacer las
modificaciones al finalizar la extracción con la ejecución de
dquilt pop -a
.
[66] El funcionamiento del sistema actual de compilación automática es más complicado que lo expuesto en este documento. Muchos detalles quedan fuera de los objetivos de este documento.
[67] Contrariamente al modo de funcionamiento del paquete pbuilder
(que se tratará más adelante), el
entorno chroot del paquete sbuild
utilizado por el sistema automático no
tiene una instalación mínima de paquetes del sistema y puede dejar muchos
paquetes instalados.
[68] Dado que el paquete pbuilder
está
evolucionando, deberías comprobar la situación de la configuración
consultando la última documentación oficial disponible.
[69] Consulta http://buildd.debian.org/ para saber más sobre la construcción automática de paquetes Debian.
[70] Se supone que la variable de entorno
HOOKDIR=/var/cache/pbuilder/hooks
ya está configurada.
Puedes consultar otros ejemplos en
/usr/share/doc/pbuilder/examples
.
[71] Hay algunas restricciones para estas actualizaciones de tu paquete
stable
.
[72] Consulta Version control systems para saber más.
[73] Debian wiki Alioth documenta cómo utilizar el servicio alioth.debian.org.
[74] La opción --pristine-tar
invoca la orden
pristine-tar la cual puede regenerar una copia exacta del
fichero comprimido de fuentes impoluto utilizando solo un pequeño fichero
binario «delta» y el contenido del fichero comprimido tipo «.tar»,
habitualmente ubicado en la rama upstream
del VCS.
[75] Aquí tienes algunos recursos disponibles en la red, dirigidos a usuarios expertos.
Construyendo paquetes Debian con «git-buildpackage»
(/usr/share/doc/git-buildpackage/manual-html/gbp.html
)
[76] Las variables de entorno que normalmente están configuradas con los valores adecuados, no se configuran con este método. Nunca cree paquetes reales para enviarlos utilizando este método rápido.