Tabla de contenidos
Vamos a construir nuestro propio paquete (o, mejor aún, adoptar un paquete ya existente).
Si estas construyendo un paquete Debian con las fuentes originales, el plan de trabajo típico implica varias etapas (en las cuales se generan archivos con nombres específicos) y que se explican a continuación:
Conseguimos las fuentes originales del programa, normalmente en un archivo comprimido en formato «tar».
nombre_del_paquete
-versión
.tar.gz
Añadir las modificaciones específicas de Debian al programa original en el
directorio debian
, y construir un paquete de fuentes no
nativo (es decir, el conjunto de archivos de entrada utilizados para la
construcción de paquetes Debian) en formato 3.0 (quilt)
).
nombre_del_paquete
_versión
.orig.tar.gz
nombre_del_paquete
_versión
-revisión
.debian.tar.gz
[4]
nombre_del_paquete
_versión
-revisión
.dsc
Construimos los paquetes binarios Debian, que son archivos instalables
ordinarios en formato .deb
(o en formato
.udeb
, utilizado por el instalador de Debian), desde el
paquete fuente de Debian.
nombre_del_paquete
_versión
-revisión
_arquitectura
.deb
Fíjate que el carácter que separa
y
nombre_del_paquete
se ha cambiado de
versión
-
(guión) a _
(guión bajo).
En los nombres de archivo que siguen,
se
substituye por el nombre del paquete,
nombre_del_paquete
por la versión del código fuente,
versión
por la revisión Debian,
revisión
por la arquitectura del paquete [5].
arquitectura
Cada paso de este esquema se explica con ejemplos detallados en secciones posteriores.
Probablemente hayas escogido ya el paquete que deseas construir. Lo primero que debes hacer es comprobar si el paquete está ya en el archivo de la distribución utilizando:
la orden aptitude
la página web Debian packages
Página web del sistema de seguimiento de paquetes de Debian.
Si el paquete ya existe, ¡instálalo! :-) Si te encuentras con que el paquete es un paquete huérfano (cuando su desarrollador es el Debian QA Group, es decir, el grupo de calidad de Debian), puedes adoptarlo (convertirte en el responsable de empaquetarlo y mantenerlo) si está disponible. También puedes adoptar un paquete para el cual se ha emitido una «solicitud de adopción» (Request for Adoption o RFA) por su desarrollador o por un DD [6].
Hay varios recursos para conocer el estado de los paquetes:
A modo de nota al margen, es importante tener presente que Debian incorpora paquetes de un gran número de programas de todo tipo, y que la cantidad de paquetes disponibles en el repositorio de Debian es mucho mayor al de colaboradores con permiso para incorporar paquetes al repositorio. En consecuencia, la colaboración en el mantenimiento de paquetes que ya están en el repositorio se valora muy positivamente (y es más fácil conseguir patrocinador) por el resto de desarrolladores [7]. Puedes hacer esto de distintas formas:
hacerte cargo de paquetes huérfanos pero que son utilizados frecuentemente por otros usuarios
incorporándote a los equipos de desarrolladores.
seleccionando errores de los paquetes más populares
preparando paquetes QA o NMU
Si puedes adoptar el paquete, descarga las fuentes (con algo como
apt-get source
) y examínalas.
Desgraciadamente este documento no incluye aún información exhaustiva sobre
la adopción de paquetes. No debería ser difícil entender cómo funciona el
paquete ya que alguien ha hecho el trabajo inicial por ti. Aún así es mejor
que sigas leyendo, muchos de los consejos que se dan a continuación serán
también aplicables en tu caso.
nombre_del_paquete
Si el paquete es nuevo y decides que te gustaría verlo en Debian debes seguir los pasos indicados a continuación:
En primer lugar deberías saber cómo funciona, y haberlo utilizado durante algún tiempo (para confirmar su utilidad).
Comprueba que no hay nadie más trabajando ya en el paquete consultando
la lista de paquetes en los que se está
trabajando. Si nadie está ya trabajando en el empaquetado del
programa, envía un informe de error de tipo ITP («Intent To Package»,
Intento de empaquetado) al meta-paquete wnpp
utilizando el programa de comunicación de
errores reportbug (accesible en el menú de herramientas
del sistema). Si ya hay alguien trabajando en él, contacta con esa persona:
es posible que podáis colaborar. En caso contrario, intenta encontrar otro
programa interesante que nadie mantenga.
El programa debe tener una licencia.
Si el paquete debe pertenecer a la sección main
el
programa debe cumplir con las Directrices de Debian
para el software libre (DFSG) y
no debe precisar la instalación de otro paquete que
no pertenezca a la sección main
para su
compilación o ejecución como requiere la directiva de Debian («Debian
Policy»). Es la situación deseada.
Para paquetes de la sección contrib
la licencia debe
cumplir todos los requisitos de la DFSG pero puede precisar la instalación
de otro paquete que no sea de la sección main
para su
compilación o ejecución.
Para paquetes de la sección non-free
, no es necesario que
la licencia cumpla todos los requisitos de la DFSG pero debe permitir la distribución del programa.
Si no estás seguro sobre en qué lugar debería ir, envía el texto de la licencia y pide consejo con un correo (en inglés) dirigido a debian-legal@lists.debian.org.
El programa no debe ocasionar problemas de seguridad y/o mantenimiento en los sistemas Debian.
El programa debería tener una buena documentación o al menos un código fuente legible y claro.
Deberías contactar con el autor o autores del programa para comprobar su conformidad con el empaquetado. Es importante que el autor o autores sigan manteniendo el programa para que puedas en el futuro consultarle/s en caso de que haya problemas específicos. No deberías intentar empaquetar programas que no estén mantenidos.
El programa no debería ejecutarse con «setuid root», o aún mejor: no debería ser «setuid» ni «setgid».
El programa no debería ser un demonio, o algo que vaya en los directorios
*/sbin
, o abrir un puerto como usuario administrador.
Por supuesto, esta lista son sólo medidas de seguridad, y con la intención de salvarte de usuarios enfurecidos si haces algo mal con algún demonio «setuid»... Cuando tengas más experiencia en empaquetar, podrás hacer este tipo de paquetes.
Como nuevo desarrollador, es aconsejable que adquieras experiencia con la construcción de paquetes sencillos y se desaconseja construir paquetes complicados.
Paquetes sencillos
archivo binario único, arquitectura = todas (colección de datos como gráficos de fondo de pantalla)
archivo binario único, arquitectura = todas (ejecutables escritos en lenguajes interpretados como POSIX)
Paquetes de complejidad intermedia
paquete binario simple, arquitectura = todas (ejecutables ELF escritos en lenguajes compilados tales como C y C + +)
paquete binario múltiple, arquitectura = todas y cualquiera (paquetes de ejecutables ELF y documentación)
paquetes en los que el formato del archivo fuente no es
tar.gz
ni tar.bz2
paquetes cuyas fuentes contienen partes que no se pueden distribuir.
Paquetes muy complejos
paquete de módulos de lenguaje interpretado utilizado por otros paquetes
paquetes de bibliotecas ELF genéricas utilizadas por otros paquetes
múltiples paquetes binarios incluyendo un paquete(s) de bibliotecas ELF
paquetes de fuentes con múltiples originales
paquetes de módulos del núcleo
paquetes de parches del núcleo,
cualquier paquete de guiones de desarrollador no triviales
Construir paquetes de alta complejidad no es demasiado difícil, pero requiere más conocimientos. Debes buscar las orientaciones específicas para cada caso según su complejidad. Por ejemplo, algunos lenguajes interpretados tienen sus normas específicas.
Hay otro dicho en latín: Fabricando fit fabe (la
práctica conduce a la perfección). Es muy recomendable
practicar y experimentar todos los pasos de la construcción de paquetes
Debian con paquetes simples mientras se lee este tutorial. Un simple archivo
hello-sh-1.0.tar.gz
generado como en el ejemplo será
un buen punto de partida [8]:
$ 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
Lo primero que debes hacer es encontrar y descargar el código fuente
original. A partir de este punto se da por supuesto que ya tienes el código
fuente que obtuviste de la página del autor. Las fuentes de los programas
libres de Unix (y GNU/Linux) generalmente vienen en formato
tar+gzip, con extensión
.tar.gz
o en formato
tar+bzip2 con extensión
.tar.bz2
, y generalmente contienen un subdirectorio
llamado
con todas las fuentes en él.
programa
-versión
Si la última versión del código fuente se puede obtener de un sistema VCS
del tipo Git, Subversion o un repositorio CVS, puedes descargarlo ejecutando
«git clone
», «cvs co
» o «svn
co
» y, a continuación comprimiéndolo en un archivo con formato
tar+gzip ejecutando la opción
«--exclude-vcs
».
Si tu programa viene en otro tipo de archivo (por ejemplo, el fichero
termina en .Z
o .zip
[9]), descomprímelo con las herramientas adecuadas y
reconstrúyelo de nuevo.
Si el código fuente del programa viene con algunos contenidos que no cumplan
con las DFSG, debes descomprimirlo para eliminar dichos contenidos y volver
a comprimirlo modificando el código de versión original añadiendo
dfsg
.
Como ejemplo, usaré el programa conocido como gentoo, un gestor de ficheros de X11 en GTK+ [10].
Crea un subdirectorio en tu directorio personal llamado
debian
o deb
o lo que creas
apropiado (por ejemplo ~/gentoo/
estaría bien en este
caso). Mueve a él el archivo que has descargado, y descomprímelo de la
siguiente forma: tar xzf gentoo-0.9.12.tar.gz
. Asegúrate
de que no hay errores, incluso errores irrelevantes,
porque es muy probable que haya problemas al desempaquetarlo en sistemas de
otras personas, cuyas herramientas de desempaquetado puede que no ignoren
estas anomalías. En el terminal de órdenes, deberías ver lo siguiente.
$ mkdir ~/gentoo ; cd ~/gentoo
$ wget http://www.example.org
/gentoo-0.9.12.tar.gz
$ tar xvzf gentoo-0.9.12.tar.gz
$ ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz
Ahora tienes otro subdirectorio, con el nombre
gentoo-0.9.12
. Accede a ese directorio y lee
atentamente la documentación. Habitualmente encontrarás
archivos con el nombre README*
,
INSTALL*
, *.lsm
o
*.html
. Deberías encontrar instrucciones sobre cómo
compilar e instalar el programa (probablemente se asumirá que la instalación
será en el directorio /usr/local/bin
, aunque tú no lo
harás eso, como se explica más adelante en Sección 3.3, “Instalación de los archivos en su destino” ).
Deberías empezar a construir tu paquete en un directorio de fuentes completamente limpio, o simplemente con las fuentes recién desempaquetadas.
Los programas sencillos incluyen un fichero Makefile
y
pueden (generalmente) compilarse con «make
»[11]. Algunos de ellos soportan make
check
, esta orden ejecuta las comprobaciones automáticas que estén
definidas. Generalmente se instalarán en sus directorios de destino
ejecutando make install
.
Ahora intenta compilar y ejecutar el programa, para asegurarte que funciona bien y que no genera errores en el sistema mientras está instalándose o ejecutándose.
También, generalmente, puedes ejecutar make clean
(o
mejor make distclean
) para limpiar el directorio donde se
compila el programa. A veces hay incluso un make
uninstall
que se puede utilizar para borrar todos los archivos
instalados.
Buena parte de los programas libres están escritos en lenguaje C y C++. Muchos
utilizan las «Autotools» y «CMake» para compilar en diferentes
plataformas. Estas herramientas se utilizan para generar un archivo
Makefile
y otros archivos necesarios para la
compilación. Así, muchos programas se compilan ejecutando «make;
make install
».
Las Autotools son el sistema de
compilación GNU e incluyen Autoconf, Automake, Libtool y
gettext. Confirmarás que el programa utiliza
las autoools por la presencia de los archivos
configure.ac
, Makefile.am
, y
Makefile.in
[12].
El primer paso en el uso de «Autotools» es la ejecución por parte del autor
de la orden autoreconf -i -f
la cual genera, a partir de
los archivos fuente (a la izquierda del gráfico) los archivos que utilizará
la orden «configure» (a la derecha del gráfico).
configure.ac-----+-> autoreconf -+-> configure Makefile.am -----+ | +-> Makefile.in src/Makefile.am -+ | +-> src/Makefile.in | +-> config.h.in automake aclocal aclocal.m4 autoheader
La edición de los archivos configure.ac
y
Makefile.am
requiere conocer el funcionamiento de
autoconf y automake. Véase
«info autoconf
» y «info automake
»
(ejecutando las órdenes en el terminal).
El segundo paso en el uso de «Autotools« es la ejecución de
«./configure && make
» en el directorio del código
fuente para compilar el programa generando un archivo
binario
.
Makefile.in -----+ +-> Makefile -----+-> make -> binary
src/Makefile.in -+-> ./configure -+-> src/Makefile -+
config.h.in -----+ +-> config.h -----+
|
config.status -+
config.guess --+
Puedes hacer cambios en el archivo Makefile
, por
ejemplo cambiando el directorio de instalación predeterminado usando las
opciones de la orden ejecutando: ./configure
--prefix=/usr.
Aunque no es necesario, la actualización del archivo
configure
y de otros archivos con la orden
autoreconf -i -f
es la mejor manera para mejorar la
compatibilidad del código fuente [13].
CMake es un sistema de compilación
alternativo. La presencia del archivo CMakeLists.txt
te
indicará que se utiliza esta opción para compilar el programa.
Si el código original se presenta como
gentoo-0.9.12.tar.gz
, puedes poner como nombre del paquete gentoo
y como
versión original
0.9.12
. Estas referencias se utilizan en el archivo
debian/changelog
descrito más adelante en Sección 4.3, “El archivo changelog
”.
Aunque este enfoque simple es útil la mayoría de las veces, es posible que debas cambiar el nombre del paquete y la versión original renombrando las fuentes originales para seguir las normas de Debian y las convenciones actuales.
Debes elegir el nombre del paquete de
forma que contenga solo letras minúsculas (a-z
), dígitos
(0-9
), el símbolo de suma (+
) y resta
(-
) y puntos (.
). Debe contener al
menos dos caracteres, empezar con un carácter alfanumérico y no coincidir
con alguno de los paquetes ya existentes. Es buena idea limitar su longitud
a un máximo de 30 caracteres [14].
Si el código fuente original utiliza palabras genéricas tales como
prueba-privada
por nombre, es buena idea cambiarlo para
no «contaminar» el espacio de nombres y para identificar su contenido en
forma explícita [15].
Debes elegir la versión original para que
tengo sólo caracteres alfanuméricos (0-9 A-Z a-z
), signo
de suma (+
), tildes (~
) y puntos
(.
). Se debe comenzar con un dígito
(0-9
) [16]. Es deseable
mantener su longitud dentro de 8 caracteres, si es posible [17].
Si el código fuente no utiliza el sistema habitual para codificar la
versión, como 2.30.32
sino que utiliza algún tipo de
fecha como 09Oct23
, una cadena de nombre en clave al azar
o un valor «hash» VCS como parte de la versión, elimínalo de la versión del código fuente. Esta información
(eliminada) puede ser registrada en el archivo
debian/changelog
. Si debes inventarte una cadena de
versión, utiliza el formato AAAAMMDD
(por ejemplo
20110429
) para la versión del código fuente. Esto asegura
que dpkg considerará correctamente las versiones
posteriores como actualizaciones. Si debes garantizar una transición fluida
al formato de versión más habitual, como 0.1
en el
futuro, utiliza 0~AAMMDD
como 0~110429
para la versión principal.
El código de la versión [18] será comparado por dpkg(1) como sigue:
$ dpkg --compare-versionsversión_1
op
versión_2
La regla de comparación de versiones se pueden resumir de la siguiente manera.
Las cadenas se comparan desde el inicio hasta el final.
Los caracteres (letras y símbolos) son anteriores a los números.
Los números se comparan como enteros.
Los caracteres (letras y símbolos) se comparan en el orden del código ASCII.
Hay algunas reglas especiales para los puntos (.
),
símbolo de suma (+
) y tildes (~
) como
se explica a continuación:
0.0
< 0.5
<
0.10
< 0.99
<
1
< 1.0~rc1
<
1.0
< 1.0+b1
<
1.0+nmu1
< 1.1
<
2.0
Uno de los casos difíciles sucede cuando la versions del código fuente
gentoo-0.9.12-ReleaseCandidate-99.tar.gz
se utiliza
como el pre-lanzamiento de gentoo-0.9.12.tar.gz
. Debes
asegurarte que la actualización funciona correctamente cambiando el nombre a
las fuentes originales por gentoo-0.9.12~rc99.tar.gz
.
Primero debes configurar las variables de entorno «shell»
$DEBEMAIL
y $DEBFULLNAME
que son
utilizadas por varias herramientas de mantenimiento de Debian para obtener
tu nombre y correo electrónico como se indica a continuación [19].
$ cat >>~/.bashrc <<EOF DEBEMAIL="tu.direccion.de.correo@ejemplo.org" DEBFULLNAME="Nombre Apellido" export DEBEMAIL DEBFULLNAME EOF $ . ~/.bashrc
Los paquetes Debian normales son paquetes no nativos construidos a partir de
los programas originales de los autores. Si deseas construir un paquete
Debian no nativo a partir del código fuente original
gentoo-0.9.12.tar.gz
, puedes construir un primer
paquete de Debian no nativo ejecutando la orden dh_make
como sigue:
$ cd ~/gentoo $ wget http://example.org/gentoo-0.9.12.tar.gz $ tar -xvzf gentoo-0.9.12.tar.gz $ cd gentoo-0.9.12 $ dh_make -f ../gentoo-0.9.12.tar.gz
Deberás cambiar el nombre del archivo por el correspondiente a tus fuentes [20]. Véase dh_make(8) para una descripción más detallada.
Saldrá alguna información. Te preguntará qué tipo de paquete deseas
construir. «gentoo» es un paquete de binario simple (crea sólo un binario)
y, por tanto, sólo un fichero .deb
- así que
seleccionaremos la primera opción, con la tecla
s
. Comprueba la información que aparece en la pantalla y
confirma pulsando la tecla
[21].
ENTER
Tras ejecutar dh_make, se genera una copia del código
original con el nombre gentoo_0.9.12.orig.tar.gz
en el
directorio raíz para facilitar la construcción del paquete de fuentes no
nativo de Debian con el archivo debian.tar.gz
:
$ cd ~/gentoo ; ls -F gentoo-0.9.12/ gentoo-0.9.12.tar.gz gentoo_0.9.12.orig.tar.gz
Observa que hay dos cambios clave en el nombre del fichero
gentoo_0.9.12.orig.tar.gz
:
El nombre del paquete y la versión están separados por
«_
».
Hay un .orig
antes de .tar.gz
.
Observa que la ejecución de la orden ha generado varios archivos de
plantilla en el directorio debian
. Se tratará sobre
ellos en Capítulo 4, Archivos necesarios en el directorio debian
y Capítulo 5, Otros ficheros en el directorio debian
.. El proceso de
empaquetado no está totalmente automatizado. Se tratará la modificación de
los archivos Debian en Capítulo 3, Modificar las fuentes. A continuación se
compilará el paquete Debian en el apartado Capítulo 6, Construyendo el paquete, la
revisión del resultado en Capítulo 7, Comprobando el paquete en busca de fallos y el envío del paquete
en Capítulo 9, Enviar el paquete. Se explicará cada una de estas etapas a
continuación.
Si accidentalmente has eliminado alguna de las plantillas mientras
trabajabas en ellas, puedes regenerarlas ejecutando
dh_make con la opción --addmissing
desde el directorio con las fuentes del paquete Debian.
Actualizar un paquete existente puede complicarse debido a que puede estar construido con técnicas más antiguas. Para aprender lo básico, es mejor limitarse a la construcción de un paquete nuevo; se amplia la explicación en Capítulo 8, Actualizar el paquete.
Ten en cuenta que el archivo de las fuentes puede que no contenga ningún
sistema de construcción discutido en Sección 2.4, “Métodos de compilación simple” y Sección 2.5, “Métodos de compilación portables populares”. Podría ser simplemente una colección datos, etc. La
instalación de archivos puede realizarse simplemente con los archivos de
configuración de debhelper
tales
como debian/install
(consulta Sección 5.11, “Archivo install
”).
[4] Para paquetes no nativos Debian construidos en el formato anterior
1.0
, se utiliza
nombre_del_paquete
_versión
-revisión
.diff.gz
[5] Consulta 5.6.1 "Source", 5.6.7 "Package", and 5.6.12 "Version". La arquitectura del paquete sigue el Debian Policy Manual, 5.6.8 "Architecture" y se asigna automáticamente en el proceso de compilación del paquete.
[7] Dicho esto, por supuesto, hay nuevos programas que vale la pena empaquetar para Debian.
[8] No debes preocuparte por perder el Makefile
. Puedes
instalar la orden hello simplemente utilizando
debhelper como en Sección 5.11, “Archivo install
”, o
modificando las fuentes originales agregando un nuevo
Makefile
con el objetivo install
como en Capítulo 3, Modificar las fuentes.
[9] Puedes identificar el formato de archivo utilizando la herramienta file cuando no es suficiente con la extensión de fichero.
[10] Ten en cuenta que el programa ya ha sido empaquetado previamente. La versión actual utiliza las «Autotools» en su construcción y ha cambiado sustancialmente de la versión 0.9.12 que se utiliza en los ejemplos mostrados a continuación.
[11]
Muchos programas modernos vienen con un guión configure
que genera un archivo Makefile
personalizado para el
sistema en uso.
[12] «Autotools» es demasiado complejo para explicarlo en este pequeño
tutorial. Esta sección tiene por objeto proporcionar sólo los conceptos
clave y referencias. Sin falta, lee el Tutorial de «Autotools» y
/usr/share/doc/autotools-dev/README.Debian.gz
si debes utilizar «Autotools».
[13] Añade el paquete dh-autoreconf
en el
campo Build-Depends
. Véase Sección 4.4.3, “Personalización del archivo rules
”.
[14] La longitud predeterminada del nombre del paquete en la orden aptitude es 30. En más del 90% de los paquetes, la longitud del nombre del paquete es inferior a 24 caracteres.
[15] Si sigues las Debian Developer's Reference 5.1. "New packages", el proceso de ITP (de «intento de empaquetado») abarcará este tipo de cuestiones.
[16] Esta norma más estricta debería ayudar a evitar confundir los nombres de archivo.
[17] El valor predeterminado para la longitud de la versión de la orden aptitude es 10. El código de la revisión Debian precedida por un guión consume 2. Para más del 80% de los paquetes, el código de la versión original es de menos de 8 caracteres y el de la revisión Debian es de menos de 2 caracteres. Para más del 90% de los paquetes, la versión original es de menos de 10 caracteres y la revisión Debian es de menos de 3 caracteres.
[18] Las cadenas de versión pueden ser la versión del
código fuente
(
), la revisión Debian
(versión
), o versión
(revisión
).
Consulta Sección 8.1, “Nueva revisión Debian del paquete” para saber cómo debe incrementarse
la revisión Debian.
versión
-revisión
[19] El texto mostrado a continuación da por supuesto que estás ejecutando «bash»
como tu intérprete de línea de órdenes. Si utilizas otros intérpretes, como
«Z shell», deberás utilizar sus correspondientes ficheros de configuración
en lugar de ~/.bashrc
.
[20] Si el archivo del código fuente original ya contiene un directorio
debian
con su contenido, ejecuta la orden
dh_make con la opción --addmissing
.
El nuevo formato 3.0 (quilt)
es lo bastante robusto para
no romper ni esos paquetes. Así se actualizará el contenido aportado por el
autor para tu paquete Debian.
[21] Se ofrecen varias opciones aquí: s
para un
binario,i
para un paquete independiente de la
arquitectura (sólo código fuente o bien documentación), m
para más de un binario, l
para una biblioteca,
k
para un módulo del núcleo («kernel»),
n
para un parche del núcleo y b
para
paquetes cdbs
. Este documento se
centra en el uso del paquete debhelper
con la orden dh
para la construcción de paquetes con un binario y trata solo parcialmente su
uso en la construcción de paquetes independientes de la arquitectura y con
más de un binario. El paquete cdbs
ofrece guiones alternativos a la orden dh y su uso queda
fuera de este documento.