Guía de empaquetamiento/Completa

De doc.ubuntu-es
< Guía de empaquetamiento(Diferencias entre revisiones)
Saltar a: navegación, buscar
(Empaquetando desde el código fuente)
m (Requisitos: retocando enlaces)
 
(No se muestran 32 ediciones intermedias realizadas por 7 usuarios)
Línea 1: Línea 1:
 +
<div style="float:right;">__TOC__</div>
 
<!-- Esto es una traducción a la velocidad del sonido por lo que es más probable que tenga faltas de todo tipo... :/ -->
 
<!-- Esto es una traducción a la velocidad del sonido por lo que es más probable que tenga faltas de todo tipo... :/ -->
{{en desarrollo|Festor}}
 
  
 
== Introducción ==
 
== Introducción ==
  
¡Bienvenido a la '''Guía de Empaquetamiento para Ubuntu'''! Esta guía pretende ser un de las principales referencias para aquellos que deseen construir y mantener paquetes Deb para [[Ubuntu]]. Asimismo muchos de los conceptos de esta guía podrían ser usados para hacer paquetes binarios para uso personal, está diseñada para aquellos que quieran distribuir sus paquetes. Aunque está orientada a la distribución GNU/Linux Ubuntu, debería ser al menos útil para cualquier distribución basada en [[Debian]].
+
¡Bienvenido a la '''Guía de Empaquetamiento para Ubuntu'''! Esta guía pretende ser una de las principales referencias para aquellos que deseen construir y mantener paquetes Deb para [[Ubuntu]]. Asimismo muchos de los conceptos de esta guía podrían ser usados para hacer paquetes binarios para uso personal, está diseñada para aquellos que quieran distribuir sus paquetes. Aunque está orientada a la distribución GNU/Linux Ubuntu, debería ser al menos útil para cualquier distribución basada en [[Debian]].
  
Hay varias razones por las que querrías aprender a empaquetar para Ubuntu. La primera, crear y arreglar paquetes *buntu es una gran forma de contribuir a la comunidad Ubuntu. También un buen camino para aprender cómo funciona Ubuntu y las aplicaciones que tienes instaladas. Quiźas quieras instalar un programa que no esté en los repositorios de Ubuntu. Ojalá después de que completes está guía tengas los suficientes conocimientos y herramientas para realizar todas estas cosas.
+
Hay varias razones por las que querrías aprender a empaquetar para Ubuntu. La primera, crear y arreglar paquetes *buntu es una gran forma de contribuir a la comunidad Ubuntu. También un buen camino para aprender cómo funciona Ubuntu y las aplicaciones que tienes instaladas. Quiźas quieras instalar un programa que no esté en los repositorios de Ubuntu. Ojalá después de que completes esta guía tengas los suficientes conocimientos y herramientas para realizar todas estas cosas.
  
 
=== Por dónde empezar ===
 
=== Por dónde empezar ===
Línea 14: Línea 14:
 
=== Requisitos ===
 
=== Requisitos ===
  
Esta guía asume que el lector tiene un conocimiento razonable a cerca de la construcción y la instalación de software desde su código fuente en distribuciones GNU/Linux. Además usaremos la [[Interfaz de Línea de Comandos]] (CLI en inglés) así que deberías defenderte bastante bien usando una [[terminal]]. Deberías ser capaz de usar al menos las siguientes herramientas:
+
Esta guía asume que el lector tiene un conocimiento razonable a cerca de la construcción y la instalación de software desde su código fuente en distribuciones GNU/Linux. Además usaremos la [[CLI:PortadaInterfaz de Línea de Comandos]] (CLI en inglés) así que deberías defenderte bastante bien usando una [[terminal]]. Deberías ser capaz de usar al menos las siguientes herramientas:
  
 
* '''make''': GNU Make es una herramienta de construcción de software muy importante. Se usa para transformar una tarea de compilación compleja en algo trivial. Es muy importante que sepas usarlo, ya que desviaremos mucha de la información del proceso de empaquetamiento en un Makefile. La documentación está disponible en la web de GNU.
 
* '''make''': GNU Make es una herramienta de construcción de software muy importante. Se usa para transformar una tarea de compilación compleja en algo trivial. Es muy importante que sepas usarlo, ya que desviaremos mucha de la información del proceso de empaquetamiento en un Makefile. La documentación está disponible en la web de GNU.
Línea 20: Línea 20:
 
* '''./configure''': Este script se incluye en casi todos los códigos fuente de programas para GNU/Linux, especialmente en programas escritos en lenguajes de programación compilados tales como C y C++. Se usa para generar un Makefile (archivo usado por make) adaptado a su sistema. Las herramientas estándar de empaquetamiento de Debian lo usan, así que es importante que sepas qué hace el script '''configure'''. Información sobre ./configure puede consultarse en la documentación del make.
 
* '''./configure''': Este script se incluye en casi todos los códigos fuente de programas para GNU/Linux, especialmente en programas escritos en lenguajes de programación compilados tales como C y C++. Se usa para generar un Makefile (archivo usado por make) adaptado a su sistema. Las herramientas estándar de empaquetamiento de Debian lo usan, así que es importante que sepas qué hace el script '''configure'''. Información sobre ./configure puede consultarse en la documentación del make.
  
* '''[[apt]]/[[dpkg]]''': Más allá del uso básico de instalar programas, apt y dpkg tienen muchas características que los hacen muy útiles para empaquetar.
+
* '''[[APT]]/[[dpkg]]''': Más allá del uso básico de instalar programas, apt y dpkg tienen muchas características que los hacen muy útiles para empaquetar.
  
 
:* <code>apt-cache dump</code> - lista cada paquete en el cache. Este comando es especialmente util en combinación con grep. Un ejemplo apt-cache dump |grep foo buscará aquelos paqetes cuyos nombres o dependencias incluyan la palabra foo.
 
:* <code>apt-cache dump</code> - lista cada paquete en el cache. Este comando es especialmente util en combinación con grep. Un ejemplo apt-cache dump |grep foo buscará aquelos paqetes cuyos nombres o dependencias incluyan la palabra foo.
Línea 121: Línea 121:
 
Requerimientos: <code>build-essential</code>, <code>automake</code>, <code>gnupg</code>, <code>lintian</code>, <code>fakeroot</code>, <code>pbuilder</code>, <code>debhelper</code> y <code>dh-make</code>.
 
Requerimientos: <code>build-essential</code>, <code>automake</code>, <code>gnupg</code>, <code>lintian</code>, <code>fakeroot</code>, <code>pbuilder</code>, <code>debhelper</code> y <code>dh-make</code>.
  
Usaremos el programa GNU hello como ejemplo. Puedes descargarte el tarball del código fuente desde ftp.gnu.org. Para el propósito de este ejemplo, usaremos el directorio <code>~/hello/</code>.
+
Usaremos el programa ''GNU hello'' como ejemplo. Puedes descargarte el tarball del código fuente desde ftp.gnu.org. Para el propósito de este ejemplo, usaremos el directorio <code>~/hello/</code>.
  
 
  mkdir ~/hello/
 
  mkdir ~/hello/
Línea 155: Línea 155:
 
  tar -xzvf hello_2.1.1.orig.tar.gz
 
  tar -xzvf hello_2.1.1.orig.tar.gz
  
La línea baja «_». entre el nombre del paquete (''hello'') y la versión (''2.1.1''), como opuesto de la línea alta «-», es muy importante. Las herramientas de empaquetado buscarán un archivo con ese nombre exacto. Si Si te equivocas, las herramientas asumirán incorrectamente que no hay código fuente original y el código fuente será construido como un paquete nativo de Debian.
+
La línea baja «_». entre el nombre del paquete (''hello'') y la versión (''2.1.1''), como opuesto de la línea alta «-», es muy importante. Las herramientas de empaquetado buscarán un archivo con ese nombre exacto. Si te equivocas, las herramientas asumirán incorrectamente que no hay código fuente original y el código fuente será construido como un paquete nativo de Debian.
  
Ahora tenemos un directorio hello que contiene los archivos del código fuente. Ahora necesitamos crear un directorio debian donde almacenaremos toda la información para construir el paquete, permitiendo serpara los archivos del paquete de los archivos del código fuente del programa. Usaremos dh_make para que cree el directorio debian con todos los archivos:
+
Ahora tenemos un directorio <code>hello/</code> que contiene los archivos del código fuente. Ahora necesitamos crear un directorio <code>debian/</code> donde almacenaremos toda la información para construir el paquete, permitiendo serpara los archivos del paquete de los archivos del código fuente del programa. Usaremos dh_make para que cree el directorio debian con todos los archivos:
  
 
  cd hello-2.1.1
 
  cd hello-2.1.1
  dh_make -e tu.dirección.de.correo.electrónico.como@mantenedor
+
  dh_make -e tu.dirección.de.correo.electrónico.como@mantenedor -f ../archivo_comprimido_que_contiene_el_código_fuente
  
Una vez ejecutado dh_make este te preguntará varios aspectos sobre tu futuro paquete:
+
El parámetro <code>-f</code> seguido del ''../archivo_comprimido_que_contiene_el_código_fuente'' se utiliza para generar una copia de respaldo del código fuente con la etiqueta '''orig''' si disponemos de un tarball con el código fuente original.
  
 
  Type of packager single binary, multiple binary, libreary, kernel module or cdbs? [s/m/l/b] s
 
  Type of packager single binary, multiple binary, libreary, kernel module or cdbs? [s/m/l/b] s
Línea 175: Línea 175:
 
  Hit <enter> to confirm: Enter
 
  Hit <enter> to confirm: Enter
  
El comando dh_make sólo se debe ejecutar una única vez. Si lo ejecutas más de una vez en el mismo directorio no funcionará correctamente. Si quieres cambiar o cometiste un error, elimina el directorio fuente y descomprime el tarball original de nuevo. Luego repite el proceso en el nuevo directorio.
+
Nos preguntará qué tipo de paquete queremos crear:
  
Al ejecutar dh_make este crear los archivos básicos en el directorio debian/ y algunos archivos plantilla (.ex) que quizas puedan ser necesarios o no. El programa Hello no es muy complicado, y una vez vista la sección "Empaquetar desde la fuente", sus requerimientos no pasan de los archivos básicos. Por ello, procederemos a eliminar los archivos .ex:
+
* La opción «s» para programas que generen un sólo paquete deb. Normalmente es la opción más utilizada.
 +
* La opción «m» genera más de un paquete deb (por ejemplo los juegos que tienen 2 paquetes juego.deb y juego-data.deb).
 +
* La opción «l» para bibliotecas.
 +
* La opción «k» se utiliza para módulos del kernel linux (algo que un empaquetador común no suele usar).
 +
* La opción «b» utiliza el programa cdbs para generar el archivo rules del paquete deb. Es una opción normalmente indicada para gente con experiencia en la empaquetamiento, aunque puede ser muy util para la que no quiera complicarse la vida.
  
  cd debian
+
Se pueden añadir las opciones <code>-s</code>, <code>-m</code>, <code>-l</code>, <code>-k</code> o <code>-b</code> detrás del email para responder directamente a esta pregunta.
 +
 
 +
El comando <code>dh_make</code> sólo se debe ejecutar una única vez. Si lo ejecutas más de una vez en el mismo directorio no funcionará correctamente. Si quieres cambiar o cometiste un error, elimina el directorio fuente y descomprime el tarball original de nuevo. Luego repite el proceso en el nuevo directorio.
 +
 
 +
Al ejecutar <code>dh_make</code> este crea los archivos básicos en el directorio <code>debian/</code> y algunos archivos plantilla (.ex) que quizás puedan ser necesarios o no. El programa ''Hello'' no es muy complicado, y una vez vista la sección [[#Empaquetando desde el código fuente|Empaquetando desde el código fuente]], sus requerimientos no pasan de los archivos básicos. Por ello, procederemos a eliminar los archivos <code>.ex</code>:
 +
 
 +
  cd debian/
 
  rm *.ex *.EX
 
  rm *.ex *.EX
  
Para hello, tampoco necesitaras algunos archivos del directorio debian:
+
Para hello, tampoco necesitaras algunos archivos del directorio <code>debian/</code>:
  
*README.Deban: El archivo README concreta aspectos del paquete Debian, NO es el archivo README del programa.
+
* <code>README.Debian</code>: el archivo README concreta aspectos del paquete Debian, NO es el archivo README del programa.
*dirs : Usado por dh_installdirs para crear los directorios necesarios.
+
* <code>dirs</code>: usado por dh_installdirs para crear los directorios necesarios.
*docs : Usado por dh_installdocs para instalar la documentación del programa.
+
* <code>docs</code>: usado por dh_installdocs para instalar la documentación del programa.
*info : Usado por dh_installinfo para instalar el archivo info.
+
* <code>info</code>: usado por dh_installinfo para instalar el archivo info.
  
Ten en cuenta que para la mayor parte de los paquetes estos archivos son necesarios. Para más información sobre ellos consulta la sección llamada "archivos de ejemplo dh_make"
+
Ten en cuenta que para la mayor parte de los paquetes estos archivos son necesarios. Para más información sobre ellos consulta la sección llamada «Archivos de ejemplo dh_make».
  
Llegados a este pinto deberías tener en el directorio debian/ sólo los archivos changelog, compat, copyright y rules.
+
Llegados a este pinto deberías tener en el directorio <code>debian/</code> sólo los archivos <code>changelog</code>, <code>compat</code>, <code>copyright</code> y <code>rules</code>.
  
 
==== changelog ====
 
==== changelog ====
  
El archivo changelog, como su nombre indica, es una lista de cambios que se hacen en cada versión. Tiene un formato específico que proporciona el nombre del paquete, la versión, la distribución, los cambios, quien hizo el paquete y cuando lo hizo. Si tienes una llave GPG, asegúrate de usar el mismo nombre y e-mail en el changelog respecto al de tu llave. Lo siguiente es un ejemplo del contenido de un archivo changelog:
+
El archivo '''<code>changelog</code>''', como su nombre indica, es una lista de cambios que se hacen en cada versión. Tiene un formato específico que proporciona el nombre del paquete, la versión, la distribución, los cambios, quien hizo el paquete y cuando lo hizo. Si tienes una llave [[GPG]], asegúrate de usar el mismo nombre y cuenta de correo en el changelog respecto al de tu llave. Lo siguiente es un ejemplo del contenido de un archivo <code>changelog</code>:
  
 
  nombre_del_paquete (versión) distribución; urgency=prioridad/urgencia
 
  nombre_del_paquete (versión) distribución; urgency=prioridad/urgencia
Línea 202: Línea 212:
 
     Más detalles sobre los cambios
 
     Más detalles sobre los cambios
 
   
 
   
   * Aún más detalles sobre los cambios
+
   * Aun más detalles sobre los cambios
 
   
 
   
 
  -- Nombre del mantenedor <correo.electrónico>  fecha_de_creación_del_paquete
 
  -- Nombre del mantenedor <correo.electrónico>  fecha_de_creación_del_paquete
  
El formato (especialmente el de la fecha) es importante. la fecha debe estar en formato RFC822 el cual se puede obtener usando el comando date -R . Tal y como veremos más adelante, el script dch te evitar preocuparte por la fecha.
+
El formato (especialmente el de la fecha) es importante. la fecha debe estar en formato ''RFC822'' el cual se puede obtener usando el comando <code>date -R</code>. Tal y como veremos más adelante, el script dch te evitar preocuparte por la fecha.
  
Aquí tenéis un ejemplo del archivo changelog para hello:
+
Aquí tenéis un ejemplo del archivo <code>changelog</code> para ''hello'':
  
 
  hello (2.1.1-0ubuntu1) hardy; urgency=low
 
  hello (2.1.1-0ubuntu1) hardy; urgency=low
Línea 216: Línea 226:
 
  -- Capki Lerrenl Fontain <packager@coolness.com>  Wed, 5 Apr 2006
 
  -- Capki Lerrenl Fontain <packager@coolness.com>  Wed, 5 Apr 2006
  
Fíjate que la versión tiene un apéndice -0ubuntu1, esta es la revisión de la distribución la cual se usa para que un paquete pueda ser actualizado (para corregir errores, por ejemplo) con nuevas versiones usando la misma versión publicada del código fuente.
+
Fíjate que la versión tiene un apéndice ''-0ubuntu1'', esta es la revisión de la distribución la cual se usa para que un paquete pueda ser actualizado (para corregir errores, por ejemplo) con nuevas versiones usando la misma versión publicada del código fuente.
  
Ubuntu y Debian tiene cambios ligeramente diferentes en los esquemas de versiones para evitar conflictos con paquetes de la misma versión del código fuente. Si un paquete Debian ha sido cambiado en Ubuntu, este tiene ubuntuX (donde X es la revisión de Ubuntu) añadido al final de la versión de Debian. Así si el paquete Debian hello 2.1.1-1 se modifica para Ubuntu la línea de versión será 2.1.1-1ubuntu1. Si un paquete de Ubuntu no existe en Debian, la revisión Debian es 0 (por ejemplo, 2.1.1-0ubuntu1)
+
Ubuntu y Debian tiene cambios ligeramente diferentes en los esquemas de versiones para evitar conflictos con paquetes de la misma versión del código fuente. Si un paquete Debian ha sido cambiado en Ubuntu, este tiene ''ubuntuX'' (donde ''X'' es la revisión de Ubuntu) añadido al final de la versión de Debian. Así si el paquete Debian ''hello 2.1.1-1'' se modifica para Ubuntu la línea de versión será ''2.1.1-1ubuntu1''. Si un paquete de Ubuntu no existe en Debian, la revisión Debian es ''0'' (por ejemplo, ''2.1.1-0ubuntu1'').
  
 
Ahora vemos el changelog para el paquete fuente que nos hemos descargado antes:
 
Ahora vemos el changelog para el paquete fuente que nos hemos descargado antes:
Línea 224: Línea 234:
 
  less ../../ubuntu/hello-debhelper-2.2/debian/changelog
 
  less ../../ubuntu/hello-debhelper-2.2/debian/changelog
  
Dese cuenta que en este caso la distribución a la que hace referencia es unstable (una rama de Debian), porque el paquete no ha sido cambiado por Ubuntu. Recuerda introducir el nombre de la distribución de tu elección.
+
Date cuenta que en este caso la distribución a la que hace referencia es ''unstable'' (una rama de Debian), porque el paquete no ha sido cambiado por Ubuntu. Recuerda introducir el nombre de la distribución de tu elección.
  
 
==== control ====
 
==== control ====
  
El archivo control contiene la información que el administrador de paquetes (como dpkg, apt-get, aptitude, synaptic y adept) usa: dependencias necesarias, información del mantenedor y muchas cosas más.
+
El archivo '''<code>control</code>''' contiene la información que el administrador de paquetes (como [[dpkg]], [[apt]], [[aptitude]], [[Synaptic]] y [[Adept]]) usa: dependencias necesarias, información del mantenedor y muchas cosas más.
  
Para el paquete hello de Ubuntu, el archivo control verás algo así:
+
Para el paquete ''hello'' de Ubuntu, el archivo <code>control</code> verás algo así:
  
 
  Section: devel
 
  Section: devel
Línea 251: Línea 261:
 
   for the GNU Project).
 
   for the GNU Project).
  
En Ubuntu se introduce en el campo de Maintainer (Mantenedor) normalmente un nombre y e-mail general ya que cualquiera puede contribuir modificando el paquete, previa revisión de los MOTU (esta es una diferencia respecto a Debian donde las modificaciones de los paquetes normalmente se asignan a equipos o personas individuales).
+
En Ubuntu se introduce en el campo de ''Maintainer'' (''Mantenedor'') normalmente un nombre y cuenta de correo general ya que cualquiera puede contribuir modificando el paquete, previa revisión de los [[MOTU]] (esta es una diferencia respecto a Debian donde las modificaciones de los paquetes normalmente se asignan a equipos o personas individuales).
  
Edita el archivo control usando la información de arriba (asegúrate de proporcionar la información del empaquetador original de Debian para el campo XSBC-Original-Maintainer).  
+
Edita el archivo <code>control</code> usando la información de arriba (asegúrate de proporcionar la información del empaquetador original de Debian para el campo ''XSBC-Original-Maintainer'').  
  
 
Ok, vamos a empezar a describir línea por línea el primer párrafo que describe el paquete fuente.
 
Ok, vamos a empezar a describir línea por línea el primer párrafo que describe el paquete fuente.
  
* '''Source:''' Indica el nombre del código fuente. Simplemente no tocar a menos que sepas lo que estas haciendo.
+
* '''Source:''' indica el nombre del código fuente. Simplemente no tocar a menos que sepas lo que estás haciendo.
* '''Section:''' Indica la categoría del paquete dentro de un repositorio apt que es reconocida por gestores de paquetes como Synaptic o Adept, pero esto no tiene nada que ver con la categoría del menú de Gnome o KDE.
+
* '''Section:''' indica la categoría del paquete dentro de un repositorio [[apt]] que es reconocida por gestores de paquetes como [[Synaptic]] o [[Adept]], no obstante esto no tiene nada que ver con la categoría del menú de [[GNOME]] o [[KDE]].
  
 
Las categorías disponibles son (puede faltar alguna):
 
Las categorías disponibles son (puede faltar alguna):
 
  
 
{| border="1" cellpadding="4" cellspacing="0"  
 
{| border="1" cellpadding="4" cellspacing="0"  
Línea 356: Línea 365:
 
|}
 
|}
  
 
+
* '''Priority:''' indica la prioridad del paquete en el sistema. Dispones de las siguientes opciones:
* '''Priority:''' Indica la prioridad del paquete en el sistema. Hay las siguientes opciones:
+
 
** '''Required''' : paquetes esenciales para que el sistema trabaje adecuadamente. Si son eliminados hay un alto riesgo de que el sistema quede inutilizarle o se rompa.
 
** '''Required''' : paquetes esenciales para que el sistema trabaje adecuadamente. Si son eliminados hay un alto riesgo de que el sistema quede inutilizarle o se rompa.
** '''Important''' : Un conjunto mínimo de paquetes para que un sistema sea usable. Eliminar estos paquetes no produce un quiebro irrecuperable de tu sistema, pero generalmente se consideran herramientas importantes sin las cuales la instalación de Linux sería incompleta. Nota: Esto no incluye cosas como Emacs o incluso el servidor X.
+
** '''Important''' : un conjunto mínimo de paquetes para que un sistema sea usable. Eliminar estos paquetes no produce un quiebro irrecuperable de tu sistema, pero generalmente se consideran herramientas importantes sin las cuales la instalación de Linux sería incompleta. Nota: Esto no incluye cosas como Emacs o incluso el servidor X.
** '''Standard''' : Poca explicación hay sobre ella.
+
** '''Standard''' : poca explicación hay sobre ella.
 
** '''Optional''' : en esencia esta categoría es para los paquetes no-requeridos, o la mayor parte de los paquetes. Sin embargo, estos paquetes no deberían presentar ningún conflicto con otros.
 
** '''Optional''' : en esencia esta categoría es para los paquetes no-requeridos, o la mayor parte de los paquetes. Sin embargo, estos paquetes no deberían presentar ningún conflicto con otros.
 
** '''Extra''' : paquetes que pueden presentar conflictos con otros paquetes en alguna de las categorías anteriores. También se usa para paquetes especializados que deberían ser únicamente útiles para aquellos quienes ya saben de ante mano el propósito del paquete/programa.
 
** '''Extra''' : paquetes que pueden presentar conflictos con otros paquetes en alguna de las categorías anteriores. También se usa para paquetes especializados que deberían ser únicamente útiles para aquellos quienes ya saben de ante mano el propósito del paquete/programa.
  
* '''Maintainer:''' Muestra el nombre del empaquetador y su correo electrónico de contacto en caso de algún problema con el paquete u otras cosas. El correo electrónico no tiene porque ser uno personal, es más si no se quiere dar basta con modificarlo con algo como email@email.com.
+
* '''Maintainer:''' muestra el nombre del empaquetador y su correo electrónico de contacto en caso de algún problema con el paquete u otras cosas. El correo electrónico no tiene porque ser uno personal, es más, si no se quiere dar basta con modificarlo con algo como ''email@email.com''.
  
Eso sí, a la hora de firmar los paquetes con claves GPG (no es siempre necesario) el correo electrónico sirve entre otras cosas para identificar la clave con la que se va a firmar.
+
Eso sí, a la hora de firmar los paquetes con claves [[GPG]] (no es siempre necesario) el correo electrónico sirve entre otras cosas para identificar la clave con la que se va a firmar.
  
* '''Standards-Version:''' Especifica la versión de la [http://www.debian.org/doc/debian-policy/ Normativa de Debian (Debian policy)] que sigue el paquete. Esta es propia de cada versión de Ubuntu y por ello los paquetes deb deben seguirla.
+
* '''Standards-Version:''' Especifica la versión de la [http://www.debian.org/doc/debian-policy/ Normativa de Debian (Debian policy)] que sigue el paquete. Esta es propia de cada versión de Ubuntu y por ello los paquetes Deb deben seguirla.
  
Para más información visitar esta web:
+
Para más información mira la [http://www.debian.org/doc/debian-policy/ documentación oficial de Debian].
  
http://www.debian.org/doc/debian-policy/
+
Este manual describe los requisitos de la política para la distribución Debian/Ubuntu GNU/Linux. Esto incluye la estructura y contenidos del archivo de Debian y varios temas de diseño del sistema operativo, así como los requisitos técnicos que cada paquete debe satisfacer para ser incluidos en la distribución.
  
Este manual describe los requisitos de la política para la distribución Debian/Ubuntu GNU/Linux. Esto incluye la estructura y contenidos del archivo de Debian y varios temas de diseño del sistema operativo, así como los requisitos técnicos que cada paquete debe satisfacer para ser incluidos en la distribución
+
Puedes averiguar la versión del Debian policy que usa tu versión de Ubuntu ejecutando este comando en una [[terminal]]:
 
+
Puedes averiguar la versión del Debian policy que usa tu versión de Ubuntu ejecutando este comando en una terminal:
+
  
 
  apt-cache show debian-policy | grep Version
 
  apt-cache show debian-policy | grep Version
  
Por lo general no debes preocuparte por ver si la versión está bien o no ya que el dh-make lo hace automáticamente, pero si estas portando un paquete de los backports de Ubuntu o Debian a otra versión de Ubuntu es probable que necesites comprobar este campo.
+
Por lo general no debes preocuparte por ver si la versión está bien o no ya que el <code>dh-make</code> lo hace automáticamente, pero si estás portando un paquete de los ''backports'' de Ubuntu o Debian a otra versión de Ubuntu es probable que necesites comprobar este campo.
  
*  '''Build-Depends:''' Está es una parte esencial del empaquetamiento del deb y quizás una de las que pueden llegar a ser un embrollo si no sabes las dependencias del paquete.
+
*  '''Build-Depends:''' esta es una parte esencial del empaquetamiento del deb y quizás una de las que pueden llegar a ser un embrollo si no sabes las dependencias del paquete.
  
*  '''Homepage:''' Una URL donde se puede encontrar más información acerca del software.
+
*  '''Homepage:''' una URL donde se puede encontrar más información acerca del software.
  
 
El siguiente párrafo es para el paquete binario que será construido a partir del código fuente. Si hay más de un paquete binario que se genere del código fuente debe haber un párrafo como el que describiremos a continuación para cada uno. De nuevo, vamos a ir línea por línea:
 
El siguiente párrafo es para el paquete binario que será construido a partir del código fuente. Si hay más de un paquete binario que se genere del código fuente debe haber un párrafo como el que describiremos a continuación para cada uno. De nuevo, vamos a ir línea por línea:
  
* '''Package:''' Esto especifica el nombre del paquete deb pero no la firma ni la etiqueta de la arquitectura. Los nombres que aparezcan en Package y Source deben ser el mismo.
+
* '''Package:''' Esto especifica el nombre del paquete deb pero no la firma ni la etiqueta de la arquitectura. Los nombres que aparezcan en ''Package'' y ''Source'' deben ser el mismo.
  
* '''Architecture:''' La arquitectura para la cual será construido el paquete/s. Algunos ejemplos son:
+
* '''Architecture:''' La arquitectura para la cual será construido el paquete. Algunos ejemplos son:
** all - El programa a empaquetar no depende de la arquitectura del sistema. Me refiero a programas hechos en Python o otros lenguajes interpretados como java. El resultado será un paquete binario cuyo nombre acabará en _all.deb.
+
** ''all'' - El programa a empaquetar no depende de la arquitectura del sistema. Se refiere a programas hechos en lenguajes interpretados o independientes de la plataforma, como [[Python]] o [[Java]]. El resultado será un paquete binario cuyo nombre acabará en ''_all.deb''.
** any - El programa a empaquetar depende de la arquitectura del sistema y debe ser compilado en todas las arquitecturas soportadas. Habrá un archivo .deb para cada arquitectura ( _i386.deb por ejemplo)
+
** ''any'' - El programa a empaquetar depende de la arquitectura del sistema y debe ser compilado en todas las arquitecturas compatibles. Habrá un archivo .deb para cada arquitectura (''_i386.deb'' por ejemplo).
  
Se puede optar por una o más de un subconjunto de arquitecturas (i386, amd64, ppc, etc.) para indicar que el programa a empaquetar depende de una arquitectura concreta y no funciona para todas las arquitecturas soportadas por Ubuntu
+
Se puede optar por una o más de un subconjunto de arquitecturas (''i386'', ''amd64'', ''ppc'', etc.) para indicar que el programa a empaquetar depende de una arquitectura concreta y no funciona para todas las arquitecturas soportadas por Ubuntu.
  
* '''Depends:''' Esto indica al sistema las dependencias del paquete deb resultante de todo el proceso, normalmente se resuelven basándose en las dependencias de construcción (''Build-Depends'') de modo que si por ejemplo indicamos allí ''programa-dev'' automáticamente el sistema sustituirá las variables ''${shlibs:Depends}'' y/o ''${misc:Depends}'' por ''programa'' (sin el -dev).
+
* '''Depends:''' esto indica al sistema las dependencias del paquete deb resultante de todo el proceso, normalmente se resuelven basándose en las dependencias de construcción (''Build-Depends'') de modo que si por ejemplo indicamos allí ''programa-dev'' automáticamente el sistema sustituirá las variables ''${shlibs:Depends}'' y/o ''${misc:Depends}'' por ''programa'' (sin el ''-dev'').
  
En algunas ocasiones (empaquetamiento de programas hechos en python, java y raras excepciones) es necesario indicar manualmente las dependencias del programa. Si se diera este caso lo más normal es añadirlas después de ''${misc:Depends}'' respetando la estructura de comas.
+
En algunas ocasiones (empaquetado de programas hechos en Python, Java y raras excepciones) es necesario indicar manualmente las dependencias del programa. Si se diera este caso lo más normal es añadirlas después de ''${misc:Depends}'' respetando la estructura de comas.
  
* '''Recommends:''' Se usa para apquetes altamente recomendados y que normalmente se instalan junto al paquete. Algunos administradores de paquetes, por ejemplo aptitude, instalan automáticamente los paquetes que pongas en este campo.
+
* '''Recommends:''' se usa para paquetes altamente recomendados y que normalmente se instalan junto al paquete. Algunos administradores de paquetes, por ejemplo [[aptitude]], instalan automáticamente los paquetes que pongas en este campo.
  
* '''Suggests:''' Se usa para paquetes que son similares o útiles cuando el paquete (que crearemos) esté instalado
+
* '''Suggests:''' se usa para paquetes que son similares o útiles cuando el paquete (que crearemos) esté instalado.
  
* '''Conflicts:''' Se usa para paquetes que presentarán problemas con este paquete. Ambos no pueden estar instalados en un mismo sistema. Si uno se instala el otro se desinstalará y viceversa.
+
* '''Conflicts:''' se usa para paquetes que presentarán problemas con este paquete. Ambos no pueden estar instalados en un mismo sistema. Si uno se instala el otro se desinstalará y viceversa.
  
* '''Description:''' Aquí describiremos el programa, esto es lo que se verá cuando abrás el archivo .deb con un programa como [[GDebi]] La descripción de un paquete deb se basa en dos partes:
+
* '''Description:''' aquí describiremos el programa, esto es lo que se verá cuando abras el archivo <code>.deb</code> con un programa como [[GDebi]]. La descripción de un paquete deb se basa en dos partes:
** Un "título" de 60 letras que va directamente después de ''Description:''
+
** Un ''título'' de 60 letras que va directamente después de ''Description:''.
** Un texto ...de unas 47 letras (no estoy seguro si se pueden más) de largo con un espacio antes de cada linea. Los espacios entre párrafos se hacen mediante un punto.
+
** Un ''texto'' de unas 47 letras (no estoy seguro si se pueden más) de largo con un espacio antes de cada línea. Los espacios entre párrafos se hacen mediante un punto.
 +
 
 +
==== copyright ====
 +
 
 +
El archivo '''<code>copyright</code>''' proporciona la información de derechos de autor. Generalmente, la información de copyright se encuentra en el archivo <code>COPYING</code> en el directorio principal del código fuente. Este archivo se debe incluir información como el nombre del empaquetador y del creador del paquete, la URL de donde conseguimos el código fuente, la licencia con el año del Copyright. Un plantilla del archivo podría ser:
 +
 
 +
This package was debianized by (Tu nombre) <tu_correo_electrónico> (Fecha)
 +
 +
It was downloaded from: (URL de la web de descarga del programa)
 +
 +
Upstream Author(s): (Nombre(s) y e-mail(s) del (los) autor(es) del programa)
 +
 +
Copyright: Copyright (C) {año(s)} por {autor(es)} {correo(s) electrónico(s)}
 +
 +
License: (Añade el texto de la licencia aquí. Para las licencias GNU basta con añadir la cabecera y
 +
  enlazar al texto completo normalmente alojado en /usr/share/common-licenses.)
 +
 +
the Ubuntu packaging:
 +
      Copyright (C) (año(s)) por (Tu nombre) <tu_correo_electrónico> (Fecha)
 +
      released under {la licencia que quieras para tu paquete}
 +
 
 +
Como ya puedes imaginar ''hello'' se libera bajo la [[w:licencia de software|licencia]] [[w:licencia pública general de GNU|GPL]]. En este caso es muy sencillo copiar el archivo copyright del paquete hello de Ubuntu:
 +
 
 +
cp ../../ubuntu/hello-debhelper-2.2/debian/copyright .
 +
 
 +
Nota que el archivo <code>copyright</code> del paquete ''hello'' de Ubuntu incluye la declaración de la licencia para el manual. Es importante que todos los archivos del código fuente estén declarados bajo una licencia.
 +
 
 +
Más información, consejos y soluciones están disponibles en la sección Copyright.
 +
 
 +
==== rules ====
 +
 
 +
El último archivo que vamos a necesitar es el '''<code>rules</code>'''. Este, prácticamente, hace todo el trabajo para crear nuestro paquete deb. Es un ''Makefile'' con instrucciones para compilar e instalar la aplicación, luego crear el archivo <code>.deb</code> a partir de los archivos instalados. También tiene instrucciones para revertir la compilación e instalación eliminando todos los archivos originales y así poder volver a disponer solo del código fuente.
 +
 
 +
Aquí tenemos una versión simplificada del <code>rules</code> creado por dh-make:
 +
 
 +
#!/usr/bin/make -f (-)
 +
 +
package = hello
 +
 +
CC = gcc
 +
CFLAGS = -g -Wall
 +
 +
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 +
  CFLAGS += -O2
 +
endif
 +
 +
#export DH_VERBOSE=1
 +
 +
clean:
 +
        dh_testdir
 +
        dh_clean
 +
        rm -f build
 +
        -$(MAKE) -i distclean
 +
 +
install: build
 +
        dh_clean
 +
        dh_installdirs
 +
        $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr \
 +
                mandir=$(CURDIR)/debian/$(package)/usr/share/man \
 +
                infodir=$(CURDIR)/debian/$(package)/usr/share/info \
 +
                install
 +
 +
build:
 +
          ./configure --prefix=/usr
 +
          $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)"
 +
          touch build
 +
 +
binary-indep: install
 +
# There are no architecture-independent files to be uploaded
 +
# generated by this package.  If there were any they would be
 +
# made here.
 +
 +
binary-arch: install
 +
        dh_testdir -a
 +
        dh_testroot -a
 +
        dh_installdocs -a NEWS
 +
        dh_installchangelogs -a ChangeLog
 +
        dh_strip -a
 +
        dh_compress -a
 +
        dh_fixperms -a
 +
        dh_installdeb -a
 +
        dh_shlibdeps -a
 +
        dh_gencontrol -a
 +
        dh_md5sums -a
 +
        dh_builddeb -a
 +
 +
binary: binary-indep binary-arch
 +
 +
.PHONY: binary binary-arch binary-indep clean checkroot
 +
 
 +
Vamos a analizar el archivo con más detalle. La primera parte que puedes ver es la declaración de algunas variables:
 +
 
 +
package = hello
 +
 +
CC = gcc
 +
CFLAGS = -g -Wall
 +
 +
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 +
  CFLAGS += -O2
 +
endif
 +
 +
#export DH_VERBOSE=1
 +
 
 +
En esta sección se exponen las banderas para el compilador y también se indica las opciones ''noopt'' para la información de depuración (debugging).
 +
 
 +
Ahora vamos a ver la sección ''build'':
 +
 
 +
build:
 +
          ./configure --prefix=/usr
 +
          $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)"
 +
          touch build
 +
 
 +
Estos comandos ejecutan el famoso <code>./configure</code> con las variables adecuadas, luego ejecutan <code>make</code> y luego hacen un registro de la construcción para prevenir compilaciones múltiples erróneas.
 +
 
 +
Las siguientes instrucciones corresponden a la sección ''clean'' en la cual se ejecuta <code>make -i distclean</code> eliminando todos los archivos que se crean durante la construcción del paquete:
 +
 
 +
clean:
 +
        dh_testdir
 +
        dh_clean
 +
        rm -f build
 +
        -$(MAKE) -i distclean
 +
 
 +
Lo próximo que veremos será unas instrucciones ''binary-indep'' vacías. Algunos paquetes se crean independientes de una arquitectura específica (como 32 o 64 bits) si no contienen archivos que necesiten de un compilador. La mayoría de los programas Python o de temas de escritorio son ejemplos de esto, sus paquetes terminan siempre en ''_all.deb''.
 +
 
 +
''hello'' es un programa escrito en [[w:lenguaje de programación C|C]] por lo que necesita de un compilador para funcionar y el resultado será un código binario diferente para cada plataforma, sus paquetes pueden terminar en ''_i386.deb'' o ''_amd64.deb'' principalmente. Para estos paquetes dependientes de una arquitectura se usa el campo ''binary-arch'':
 +
 
 +
binary-arch: install
 +
        dh_testdir -a
 +
        dh_testroot -a
 +
        dh_installdocs -a NEWS
 +
        dh_installchangelogs -a ChangeLog
 +
        dh_strip -a
 +
        dh_compress -a
 +
        dh_fixperms -a
 +
        dh_installdeb -a
 +
        dh_shlibdeps -a
 +
        dh_gencontrol -a
 +
        dh_md5sums -a
 +
        dh_builddeb -a
 +
 
 +
Aquí se ponen en funcionamiento una serie de scripts ''debhelper'' que crean nuestros paquetes deb. ''dh_testdir'' y ''dh_testroot'' hacen algunas comprobaciones de la estructura. ''dh_installdocs'' y ''dh_installchangelogs'' instala los archivos que especifiques en los archivos *.doc y *.changelog. ''dh_strip'' tomará la información de depuración (debugging symbols) y la apartará de la aplicación reduciendo drásticamente su tamaño. ''dh_compress'' ejecuta [[gzip]] (un compresor de consola) para comprimir alguna documentación. ''dh_shlibdeps'' añade las librerías dependientes al campo "Depends: ${shlibs:Depends}" en el archivo debian/control. Finalmente ''dh_builddeb'' construye nuestro archivo .deb. Tranquilo, no te debes preocupar mucho acerca de estos scripts, normalmente crean el paquete sin problemas.
 +
 
 +
Hay otro archivo, <code>compat</code>, el cual contiene el número de la versión de los scripts debhelper. De vez en cuando se publican nuevas versiones del debhelper, la versión actual es la 6 (en Ubuntu 8.04). Si se introduce una versión más antigua entonces los scripts debhelper puede que funcionen ligeramente diferente.
 +
 
 +
==== Construyendo el paquete ====
 +
 
 +
Ya estás listo para construir le paquete. Para ello simplemente ejecutaremos el comando:
 +
 
 +
debuild
 +
 
 +
''Debuild'' comprobará primero si el paquete <code>build-depends</code> está instalado, luego usará <code>dpkg-buildpackage</code> para compilar, instalar y construir el o los paquetes deb usando las indicaciones del archivo <code>debian/rules</code>. Si todo está bien debuild intentará firmar digitalmente el o los paquetes con [[GPG]], si te da un error de que no ha encontrado ninguna llave GPG significa que se ha creado correctamente el paquete deb pero tú no tienes una llave GPG con el mismo nombre y correo que el que usaste en el archivo <code>debian/changelog</code>.
 +
 
 +
Tu nuevo paquete debería estar en el directorio superior al código fuente. Échale un vistazo e instálalo:
 +
 
 +
cd ..
 +
lesspipe *deb
 +
sudo dpkg --install *.deb
 +
 
 +
==== Construyendo el paquete fuente ====
 +
 
 +
Ahora, una vez que hemos analizado los archivos del directorio <code>debian/</code> en profundidad, podemos construir el paquete fuente (y también los paquetes binarios). Primero vamos a movernos al directorio principal en el que extrajimos el código fuente para construir el paquete usando debuild:
 +
 
 +
debuild -S
 +
 
 +
Este comando hace que el sistema tome como referencia el <code>.orig.tar.gz</code> para crear un archivo <code>.dsc</code> que contiene la descripción y el <code>md5sum</code> para el paquete fuente y un archivo <code>.diff.gz</code> en el cual se compara el código fuente comprimido (<code>.orig.tar.gz</code>) con el descomprimido en donde se halla el directorio <code>debian/</code>. Los archivos <code>.dsc</code> y <code>*_source.changes</code> usados para subir el paquete fuente serán firmados usando tu llave GPG.
 +
 
 +
La opción <code>-S</code> le dice al debuild que construya el paquete fuente usando los scripts ''dpkg-buildpackage'' y ''[[fakeroot]]'' para poder simular privilegios de administrador (root) cuando se construye el paquete.
 +
 
 +
Si no tienes una clave GPG configurada en el sistema recibirás un error del debuild. Puedes crear e instalar una clave GPG o usar las opciones <code>-us -uc</code> con debuild para no firmar digitalmente el paquete. Sin embargo, no serás capaz de subir tus paquetes a Ubuntu sin firmarlos. Para asegurarte de que debuild encuentre correctamente la clave GPG debes introducir las variables de entorno <code>DEBFULLNAME</code> y <code>DEBEMAIL</code>, en el script de inicio de tu intérprete de comandos (<code>~/.bashrc</code> en [[bash]], por ejemplo), con el nombre y el cuenta de correo electrónico respectivamente que uses para la clave GPG y en el archivo <code>debian/changelog</code>.
 +
 
 +
Algunos usuarios han reportado que les fue imposible que debuild encontrara la clave GPG incluso después de introducir las variables. Si este fuera tu caso puedes probar con el comando:
 +
 
 +
debuild  -k <id_clave_GPG>
 +
 
 +
Donde <id_clave_GPG> es el identificativo de tu clave GPG.
 +
 
 +
Para comprobar que el paquete se construya en un entorno limpio también podemos construir el paquete binario con ''pbuilder'':
 +
 
 +
sudo pbuilder build ../*.dsc
 +
 
 +
Usando ''pbuilder'' podemos saber si las dependencias son correctas ya que este proporciona un entorno mínimo así que todas las dependencias quedarían determinadas por el archivo <code>control</code>.
 +
 
 +
Ahora podemos comprobar los errores comunes en el paquete fuente usando ''lintian'':
 +
 
 +
cd ..
 +
lintian -i *.dsc
 +
 
 +
==== Requisitos de paquetes nuevos para Ubuntu ====
 +
 
 +
Cuando un paquete fuente, que aún no existe, se sube a Ubuntu o se construye un nuevo paquete binario debe ser colocado en la lista NEW y tienen que ser revisado por un miembro del equipo del archivo de Ubuntu
 +
 
 +
===== Empaquetado =====
 +
 
 +
* Lo más importante: Mirar los derechos de autor (copyright) y la información de la licencia antes de nada.
 +
* El paquete fuente y el paquete binario deben tener un nombre "sano": ni uno demasiado corto (como "editor") ni uno extremadamente largo y sin sentido (como "nuevo-cool-administrador")
 +
* debian/control y debian/rules deben construir paquetes con Architecture:, Build-Depends[-Indep]: correctos, y el archivo rules debe tener muy presente la relación  (binary-arch vs. binary-indep).
 +
* Los scripts de mantenimiento del paquete no deben estropear demasiado el sistema
 +
* ...
 +
 
 +
===== Otros =====
 +
*La [http://ftp-master.debian.org/REJECT-FAQ.html nueva FAQ de Debian] sobre rechazos enumera algunos casos especiales de importancia que en la mayoría de los casos aplica a Ubuntu.
 +
*Procesos de documentación: [https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages UbuntuDevelopment/NewPackages]
 +
 
 +
=== Empaquetando con CDBS ===
 +
 
 +
...
 +
 
 +
=== Empaquetando módulos Python con CDBS ===
 +
 
 +
...
 +
 
 +
=== Empaquetado avanzado ===
 +
 
 +
...
 +
 
 +
==== Creando más de un paquete binario ====
 +
 
 +
...
 +
 
 +
=== Empaquetando librerías compartidas ===
 +
Este documento explica qué son las bibliotecas compartidas, centrándose en símbolos exportados y explica algunos de los detalles de cómo empaquetarlos.
 +
 
 +
 
 +
 
 +
==== Librerías compartidas ====
 +
 
 +
...
 +
 
 +
=== Errores comunes ===
 +
 
 +
...
 +
 
 +
==== Archivos de ejemplo dh-make ====
 +
 
 +
...
 +
 
 +
==== Abusando de archivos ====
 +
 
 +
...
 +
 
 +
==== Cambiando el tarball original ====
 +
 
 +
...
 +
 
 +
===== Soluciones =====
 +
 
 +
...
 +
 
 +
===== Consejos =====
 +
 
 +
...
 +
 
 +
==== Información de Copyright ====
 +
 
 +
...
 +
 
 +
==== Paquetes de referencia ====
 +
 
 +
...
 +
 
 +
== Sistema de parches ==
 +
 
 +
== KDE ==
 +
 
 +
== Archivos complementarios ==
 +
 
 +
== Recetas ==
 +
 
 +
== Apéndice ==
  
 
== Fuentes ==
 
== Fuentes ==
  
 
* https://wiki.ubuntu.com/PackagingGuide/Complete.
 
* https://wiki.ubuntu.com/PackagingGuide/Complete.
 +
 +
[[Categoría:Gestión de paquetes]]

Última revisión de 11:50 20 mayo 2012

Contenido

[editar] Introducción

¡Bienvenido a la Guía de Empaquetamiento para Ubuntu! Esta guía pretende ser una de las principales referencias para aquellos que deseen construir y mantener paquetes Deb para Ubuntu. Asimismo muchos de los conceptos de esta guía podrían ser usados para hacer paquetes binarios para uso personal, está diseñada para aquellos que quieran distribuir sus paquetes. Aunque está orientada a la distribución GNU/Linux Ubuntu, debería ser al menos útil para cualquier distribución basada en Debian.

Hay varias razones por las que querrías aprender a empaquetar para Ubuntu. La primera, crear y arreglar paquetes *buntu es una gran forma de contribuir a la comunidad Ubuntu. También un buen camino para aprender cómo funciona Ubuntu y las aplicaciones que tienes instaladas. Quiźas quieras instalar un programa que no esté en los repositorios de Ubuntu. Ojalá después de que completes esta guía tengas los suficientes conocimientos y herramientas para realizar todas estas cosas.

[editar] Por dónde empezar

Si eres completamente nuevo en la creación de paquetes deb entonces deberías leerte esta guía de principio a fin, prestando especial atención a las secciones Requisitos y Empaquetado básico. Gente con cierta experiencia en el tema encontrará cosas más útiles en la secciones Empaquetado y Errores comunes.

[editar] Requisitos

Esta guía asume que el lector tiene un conocimiento razonable a cerca de la construcción y la instalación de software desde su código fuente en distribuciones GNU/Linux. Además usaremos la CLI:PortadaInterfaz de Línea de Comandos (CLI en inglés) así que deberías defenderte bastante bien usando una terminal. Deberías ser capaz de usar al menos las siguientes herramientas:

  • make: GNU Make es una herramienta de construcción de software muy importante. Se usa para transformar una tarea de compilación compleja en algo trivial. Es muy importante que sepas usarlo, ya que desviaremos mucha de la información del proceso de empaquetamiento en un Makefile. La documentación está disponible en la web de GNU.
  • ./configure: Este script se incluye en casi todos los códigos fuente de programas para GNU/Linux, especialmente en programas escritos en lenguajes de programación compilados tales como C y C++. Se usa para generar un Makefile (archivo usado por make) adaptado a su sistema. Las herramientas estándar de empaquetamiento de Debian lo usan, así que es importante que sepas qué hace el script configure. Información sobre ./configure puede consultarse en la documentación del make.
  • APT/dpkg: Más allá del uso básico de instalar programas, apt y dpkg tienen muchas características que los hacen muy útiles para empaquetar.
  • apt-cache dump - lista cada paquete en el cache. Este comando es especialmente util en combinación con grep. Un ejemplo apt-cache dump |grep foo buscará aquelos paqetes cuyos nombres o dependencias incluyan la palabra foo.
  • apt-cache policy - lista el repositorio (main/restricted/universe/multiverse) en cual existe el paquete.
  • apt-cache show - mostrar información acerca de un paquete binario
  • apt-cache showsrc - mostrar información acerca de un código fuente
  • apt-cache rdepends - muestra las dependencias invertidas para un paquete
  • dpkg -S - lista el/los paquete/s binario/s al cual/es pertenece un archivo en particular
  • dpkg -l - lista los paquetes que tengas instalados en el sistema
  • dpkg -c -lista el contenido de un paquete binario. Es util para asegurarse de que los archivos se instalan en los lugares correctos.
  • dpkg -f muestra el archivo control de un paquete binario. Es útil para asegurarse de que las dependencias son correctas.
  • grep-dctrl - busca información especializada en los paquetes. Es un uso específico de la herramienta grep (pero no instalado por defecto)
  • diff y patch:
  • El programa diff se puede usar para comparar 2 archivos y de este modo crear parches. Un ejemplo típico podría ser:
diff -ruN archivo.antiguo archivo.nuevo > archivo.diff

Este comando creará un archivo .diff que mostrará los cambios entre 2 archivos.

  • El programa patch es usado para aplicar un parche (normalmente creado por diff o otro programa similar). Para aplicar el parche utiliza el comando:
patch -p0 < archivo.diff

El parámetro -p le dice a patch cómo debe formatear los nombres de archivo en el parche. La opción -p0 significa que deja el parche intacto.

[editar] Empezando

[editar] Paquetes binarios y paquetes fuente

La mayoría de los usuarios de una distribución basada en Debian como Ubuntu nunca van a tener que tratar con el código fuente que se usa para crear todos los programas que usen en sus ordenadores. En vez de eso, el código fuente se compila en paquetes binarios a partir de un paquete fuente que contiene ambos: el código fuente en sí mismo y las instrucciones para crear el paquete binario. Los mantenedores de paquetes suben el código fuente con los cambios a sistemas de empaquetado que compilan los paquetes binarios para cada arquitectura. Un sistema independiente distribuye los archivos binarios .deb generados y el código fuente con las instrucciones a cada repositorios espejo.

[editar] Herramientas de empaquetado

Hay muchas herramientas escritas específicamente para empaquetar en sistemas basados en Debian. Muchas de ellas no fueron creadas con la intención de empaquetar programas pero son realmente útiles y suelen automatizar tareas repetitivas. Sus páginas man e info son buenas fuentes de información. Sin embargo, la lista de paquetes son extremadamente necesarios para comenzar a empaquetar.

  • build-essential es un metapaquete que depende de libc6-dev, gcc, g++, make y dpkg-dev. Uno de los paquetes con los que podrías no estar familiarizado es dpkg-dev. Este contiene herramientas de la talla de dpkg-buildpackage y dpkg-source que se usan para crear, desempaquetar y construir paquetes binarios o fuentes.
  • devscripts contiene muchos scripts que facilitan considerablemente la tareas de un mantenedor de paquetes. Algunos de los más usados son debdiff, dch, debuild y debsing.
  • ubuntu-dev-tools también contiene una colección de scripts (al igual que devscripts), pero específicos para Ubuntu. Contiene herramientas como update-maintainer, dgetlp, what-patch, pbuilder-dist, etc.
  • debhelper son un conjunto de scripts que realizan tareas comunes de empaquetado.
  • dh-make se usa para crear una plantilla para tu futuro paquete.
  • diff y patch se usan para crear y aplicar parches, respectivamente. Su uso está muy extendido ya que son faciles de usar, limpios y más eficientes que modificar el código fuente a lo bruto.
  • quilt administra los parches.
  • gnupg es un completo y libre reemplazo para PGP usado para firmar digitalmente archivos (incluyendo paquetes).
  • fakeroot simula ejecutar comandos con privilegios de root. Es útil para crear paquetes binarios para uso personal.
  • lintian y linda diseccionan paquetes Debian y avisan de errores y violaciones de la normativa. Contienen autómatas que revisan muchos aspectos de la Normativa Debian así como otros errores comunes. linda no está disponible desde los repositorios de Ubuntu 8.04, pero aún está disponible en repositorios de lanzamientos anteriores.
  • pbuilder crea un sistema chroot y construye un paquete en el mismo. Es un sistema ideal para comprobar si un paquete se realiza correctamente, revisar sus dependencias y construir paquetes para probar y distribuir.

[editar] Empaquetador personal: pbuilder

Usar pbuilder como un constructor de paquetes te permitirá crear paquetes sin necesidad de un entorno chroot. Puedes construir paquetes sin usar pbuilder, pero tendrás todas las dependencias instaladas en tu sistema muchas de las cuales no necesitarías (librerías de desarrollo y similares). Sin embargo, pbuilder permite al empaqeutador comprobar las dependencias de constucción ya que el paquete se construye con una instalación mínima de Ubuntu, y las dependencias de construcción serán descargadas de acuerdo con el archivo debian/control.

Un manual de uso rápido:

  • Para crear un entorno pbuilder, ejecuta:
sudo pbuilder create --distribution <versión de ubuntu> \
--othermirror "deb http://archive.ubuntu.com/ubuntu <versión de ubuntu> main restricted ubiverse multiverse"
  • Para construir un paquete usando pbuidler, ejecuta:
sudo pbuilder build *.dsc
  • Para actualizar un entorno pbuilder, ejecuta:
sudo pbuilder update
  • Usa pbuidler-dist (del paquete ubuntu-dev-tools) para tener distintas instalaciones de pbuidler para las diferentes lanzamientos de Ubuntu.

[editar] Empaquetado básico

Dos de los problemas a los que se enfrentan la mayoría de los nuevos empaquetadores son las múltiples formas de crear paquetes deb y el hecho de que existan diversas herramientas para hacer lo mismo.

El desarrollo de un paquete suele necesitar de la instalación de muchos otros paquetes (especialmente paquetes -dev que contiene las cabeceras (headers) y otros archivos comunes de desarrollo) que no forman parte de una instalación normal de escritorio de Ubuntu. Si quieres evitar la instalación de paquetes extra o deseas desarrollar para una versión de Ubuntu distinta a la que usas (la versión en desarrollo por ejemplo) el uso de un entorno chroot es altamente recomendable.

Vamos a exponer dos ejemplos de sistemas de construcción comunes. Usaremos debhelper, el sistema de construcción más popular en Debian. Este ayuda al empaquetador automatizando tareas repetitivas. Luego vamos a cubrir brevemente el Sistema de Construcción Común para Debian (Common Debian Build System, CDBS) un sistema más automatizado que utiliza debhelper.

[editar] Empaquetando desde el código fuente

Requerimientos: build-essential, automake, gnupg, lintian, fakeroot, pbuilder, debhelper y dh-make.

Usaremos el programa GNU hello como ejemplo. Puedes descargarte el tarball del código fuente desde ftp.gnu.org. Para el propósito de este ejemplo, usaremos el directorio ~/hello/.

mkdir ~/hello/
cd ~/hello/
wget http://ftp.gnu.org/gnu/hello/hello-2.1.1.tar.gz

Si estás empaquetando tu propio código fuente o el programa no está disponible en un archivo .tar.gz, puedes crear el archivo .tar.gz necesario desde el directorio que lo contenga con el siguiente comando:

tar czf hello-2.1.1.tar.gz hello-2.1.1

Para el propósito de este ejemplo, también compararemos nuestro paquete (hello) con uno que ya está empaquetado en el repositorio de ubuntu (bajo el nombre hello-debhelper). Por ahora nos centraremos en el directorio hello así que podremos mirar el paquete de los repositorios despues. Para conseguir el código fuente, asegúrate de tener una línea «deb-src» del repositorio principal en tu /etc/apt/sources.list. Entonces simplemente ejecuta:

mkdir ubuntu/
cd ubuntu/
apt-get source hello-debhelper
cd ..

A diferencia de la mayoría de los comandos apt-get, no necesitaras privilegios de administrador (root) para conseguir el paquete fuente, ya que se descarga en el directorio actual. De echo, es recomendable que sólo uses apt-get source como usuario normal, ya que de esta forma puedes editar archivos en el paquete fuente sin necesidad de privilegios de administrador. El comando apt-get source:

  • Descarga el paquete fuente. Un paquete fuente normalmente contiene un archivo .dsc que describe el paquete y proporciona el md5sums para el paquete fuente, un archivo .orig.tar.gz que contiene el código fuente del autor/es del programa, un archivo .diff.gz que contiene las instrucciones de empaquetado (en el directorio debian/) y los parches que se aplicarán en el código fuente.
  • Descomprime el archivo .orig.tar.gz en el directorio actual.
  • Aplica el .diff.gz al directorio del código fuente.

Si te has descargado manualmente el paquete fuente (los archivos .dsc, .orig.tar.gz y .diff.gz) puedes desempaquetarlos de la misma manera que el apt-get source con el comando:

dpkg-source -x *.dsc

Nosotros queremos recrear lo anterior desde el código fuente. Lo primero que necesitaras es hacer una copia (algunas veces llamado «upstream») del tarball de forma que quede con el siguiente formato: <paquete>_<versión>.orig.tar.gz. Con esto conseguir crear una copia del código fuente por si accidentalmente cambias o eliminas algo en el que estas trabajando. También debemos tener en cuenta que se considera una forma de actuar no muy aceptada modificar el código fuente original a menos que sea absolutamente necesario.

cp hello-2.1.1.tar.gz hello_2.1.1.orig.tar.gz
tar -xzvf hello_2.1.1.orig.tar.gz

La línea baja «_». entre el nombre del paquete (hello) y la versión (2.1.1), como opuesto de la línea alta «-», es muy importante. Las herramientas de empaquetado buscarán un archivo con ese nombre exacto. Si te equivocas, las herramientas asumirán incorrectamente que no hay código fuente original y el código fuente será construido como un paquete nativo de Debian.

Ahora tenemos un directorio hello/ que contiene los archivos del código fuente. Ahora necesitamos crear un directorio debian/ donde almacenaremos toda la información para construir el paquete, permitiendo serpara los archivos del paquete de los archivos del código fuente del programa. Usaremos dh_make para que cree el directorio debian con todos los archivos:

cd hello-2.1.1
dh_make -e tu.dirección.de.correo.electrónico.como@mantenedor -f ../archivo_comprimido_que_contiene_el_código_fuente 

El parámetro -f seguido del ../archivo_comprimido_que_contiene_el_código_fuente se utiliza para generar una copia de respaldo del código fuente con la etiqueta orig si disponemos de un tarball con el código fuente original.

Type of packager single binary, multiple binary, libreary, kernel module or cdbs? [s/m/l/b] s
Maintainer name : Tu nombre
Email-Address : tu.dirección.de.correo.electrónico.como@mantenedor
Date: Thu, 6 Aprt 2008 10:07:19 -0700
Package Name : hello
Version : 2.1.1
License : blank
Type of Package : Single
Hit <enter> to confirm: Enter

Nos preguntará qué tipo de paquete queremos crear:

  • La opción «s» para programas que generen un sólo paquete deb. Normalmente es la opción más utilizada.
  • La opción «m» genera más de un paquete deb (por ejemplo los juegos que tienen 2 paquetes juego.deb y juego-data.deb).
  • La opción «l» para bibliotecas.
  • La opción «k» se utiliza para módulos del kernel linux (algo que un empaquetador común no suele usar).
  • La opción «b» utiliza el programa cdbs para generar el archivo rules del paquete deb. Es una opción normalmente indicada para gente con experiencia en la empaquetamiento, aunque puede ser muy util para la que no quiera complicarse la vida.

Se pueden añadir las opciones -s, -m, -l, -k o -b detrás del email para responder directamente a esta pregunta.

El comando dh_make sólo se debe ejecutar una única vez. Si lo ejecutas más de una vez en el mismo directorio no funcionará correctamente. Si quieres cambiar o cometiste un error, elimina el directorio fuente y descomprime el tarball original de nuevo. Luego repite el proceso en el nuevo directorio.

Al ejecutar dh_make este crea los archivos básicos en el directorio debian/ y algunos archivos plantilla (.ex) que quizás puedan ser necesarios o no. El programa Hello no es muy complicado, y una vez vista la sección Empaquetando desde el código fuente, sus requerimientos no pasan de los archivos básicos. Por ello, procederemos a eliminar los archivos .ex:

cd debian/
rm *.ex *.EX

Para hello, tampoco necesitaras algunos archivos del directorio debian/:

  • README.Debian: el archivo README concreta aspectos del paquete Debian, NO es el archivo README del programa.
  • dirs: usado por dh_installdirs para crear los directorios necesarios.
  • docs: usado por dh_installdocs para instalar la documentación del programa.
  • info: usado por dh_installinfo para instalar el archivo info.

Ten en cuenta que para la mayor parte de los paquetes estos archivos son necesarios. Para más información sobre ellos consulta la sección llamada «Archivos de ejemplo dh_make».

Llegados a este pinto deberías tener en el directorio debian/ sólo los archivos changelog, compat, copyright y rules.

[editar] changelog

El archivo changelog, como su nombre indica, es una lista de cambios que se hacen en cada versión. Tiene un formato específico que proporciona el nombre del paquete, la versión, la distribución, los cambios, quien hizo el paquete y cuando lo hizo. Si tienes una llave GPG, asegúrate de usar el mismo nombre y cuenta de correo en el changelog respecto al de tu llave. Lo siguiente es un ejemplo del contenido de un archivo changelog:

nombre_del_paquete (versión) distribución; urgency=prioridad/urgencia

 * Detalles sobre los cambios
   Más detalles sobre los cambios

 * Aun más detalles sobre los cambios

-- Nombre del mantenedor <correo.electrónico>  fecha_de_creación_del_paquete

El formato (especialmente el de la fecha) es importante. la fecha debe estar en formato RFC822 el cual se puede obtener usando el comando date -R. Tal y como veremos más adelante, el script dch te evitar preocuparte por la fecha.

Aquí tenéis un ejemplo del archivo changelog para hello:

hello (2.1.1-0ubuntu1) hardy; urgency=low

 * Nueva versión con muchos errores corregidos

-- Capki Lerrenl Fontain <packager@coolness.com>  Wed, 5 Apr 2006

Fíjate que la versión tiene un apéndice -0ubuntu1, esta es la revisión de la distribución la cual se usa para que un paquete pueda ser actualizado (para corregir errores, por ejemplo) con nuevas versiones usando la misma versión publicada del código fuente.

Ubuntu y Debian tiene cambios ligeramente diferentes en los esquemas de versiones para evitar conflictos con paquetes de la misma versión del código fuente. Si un paquete Debian ha sido cambiado en Ubuntu, este tiene ubuntuX (donde X es la revisión de Ubuntu) añadido al final de la versión de Debian. Así si el paquete Debian hello 2.1.1-1 se modifica para Ubuntu la línea de versión será 2.1.1-1ubuntu1. Si un paquete de Ubuntu no existe en Debian, la revisión Debian es 0 (por ejemplo, 2.1.1-0ubuntu1).

Ahora vemos el changelog para el paquete fuente que nos hemos descargado antes:

less ../../ubuntu/hello-debhelper-2.2/debian/changelog

Date cuenta que en este caso la distribución a la que hace referencia es unstable (una rama de Debian), porque el paquete no ha sido cambiado por Ubuntu. Recuerda introducir el nombre de la distribución de tu elección.

[editar] control

El archivo control contiene la información que el administrador de paquetes (como dpkg, apt, aptitude, Synaptic y Adept) usa: dependencias necesarias, información del mantenedor y muchas cosas más.

Para el paquete hello de Ubuntu, el archivo control verás algo así:

Section: devel
Priority: optional
Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
XSBC-Original-Maintainer: Captain Packager <packager@coolness.com>
Standards-Version: 3.7.3
Build-Depends: debhelper (>= 5)
Homepage: http://www.gnu.org/software/hello/

Package: hello
Architecture: any
Depends: ${shlibs:Depends}
Description: The classic greeting, and a good example
 The GNU hello program produces a familiar, friendly greeting. It
 allows non-programmers to use a classic computer science tool which
 would otherwise be unavailable to them. . Seriously, though: this is
 an example of how to do a Debian package. It is the Debian version of
 the GNU Project's `hello world' program (which is itself an example
 for the GNU Project).

En Ubuntu se introduce en el campo de Maintainer (Mantenedor) normalmente un nombre y cuenta de correo general ya que cualquiera puede contribuir modificando el paquete, previa revisión de los MOTU (esta es una diferencia respecto a Debian donde las modificaciones de los paquetes normalmente se asignan a equipos o personas individuales).

Edita el archivo control usando la información de arriba (asegúrate de proporcionar la información del empaquetador original de Debian para el campo XSBC-Original-Maintainer).

Ok, vamos a empezar a describir línea por línea el primer párrafo que describe el paquete fuente.

  • Source: indica el nombre del código fuente. Simplemente no tocar a menos que sepas lo que estás haciendo.
  • Section: indica la categoría del paquete dentro de un repositorio apt que es reconocida por gestores de paquetes como Synaptic o Adept, no obstante esto no tiene nada que ver con la categoría del menú de GNOME o KDE.

Las categorías disponibles son (puede faltar alguna):

Nombre Descripción Nombre Descripción Nombre Descripción Nombre Descripción
admin Administración del sistema kde Escritorio KDE shells Shells graphics Gráficos
base Sistema base libs Librerías sound Sonido y vídeo comm Comunicación
libdevel Librerías de desarrollo tex TeX, autoría contrib Contrib mail Correo electrónico
utils Utilidades/Herramientas devel Desarrollo math Matemáticas web Web (World Wide Web)
doc Documentación misc Miscelaneaos - Basados en texto x11 Misceláneos - Gráficos editors Editores
net Redes interpreters Lenguajes de ordenador interpretados electronics Electrónica news Grupos de noticias
science Ciencia embedded Dispositivos integrados non-free No libre hamradio Radio
games Juegos oldlibs Librerías antiguas python Lenguaje de programación Python gnome Escritorio Gnome
otherosfs Plataformas cruzadas perl Lenguaje de programación Perl
  • Priority: indica la prioridad del paquete en el sistema. Dispones de las siguientes opciones:
    • Required : paquetes esenciales para que el sistema trabaje adecuadamente. Si son eliminados hay un alto riesgo de que el sistema quede inutilizarle o se rompa.
    • Important : un conjunto mínimo de paquetes para que un sistema sea usable. Eliminar estos paquetes no produce un quiebro irrecuperable de tu sistema, pero generalmente se consideran herramientas importantes sin las cuales la instalación de Linux sería incompleta. Nota: Esto no incluye cosas como Emacs o incluso el servidor X.
    • Standard : poca explicación hay sobre ella.
    • Optional : en esencia esta categoría es para los paquetes no-requeridos, o la mayor parte de los paquetes. Sin embargo, estos paquetes no deberían presentar ningún conflicto con otros.
    • Extra : paquetes que pueden presentar conflictos con otros paquetes en alguna de las categorías anteriores. También se usa para paquetes especializados que deberían ser únicamente útiles para aquellos quienes ya saben de ante mano el propósito del paquete/programa.
  • Maintainer: muestra el nombre del empaquetador y su correo electrónico de contacto en caso de algún problema con el paquete u otras cosas. El correo electrónico no tiene porque ser uno personal, es más, si no se quiere dar basta con modificarlo con algo como email@email.com.

Eso sí, a la hora de firmar los paquetes con claves GPG (no es siempre necesario) el correo electrónico sirve entre otras cosas para identificar la clave con la que se va a firmar.

  • Standards-Version: Especifica la versión de la Normativa de Debian (Debian policy) que sigue el paquete. Esta es propia de cada versión de Ubuntu y por ello los paquetes Deb deben seguirla.

Para más información mira la documentación oficial de Debian.

Este manual describe los requisitos de la política para la distribución Debian/Ubuntu GNU/Linux. Esto incluye la estructura y contenidos del archivo de Debian y varios temas de diseño del sistema operativo, así como los requisitos técnicos que cada paquete debe satisfacer para ser incluidos en la distribución.

Puedes averiguar la versión del Debian policy que usa tu versión de Ubuntu ejecutando este comando en una terminal:

apt-cache show debian-policy | grep Version

Por lo general no debes preocuparte por ver si la versión está bien o no ya que el dh-make lo hace automáticamente, pero si estás portando un paquete de los backports de Ubuntu o Debian a otra versión de Ubuntu es probable que necesites comprobar este campo.

  • Build-Depends: esta es una parte esencial del empaquetamiento del deb y quizás una de las que pueden llegar a ser un embrollo si no sabes las dependencias del paquete.
  • Homepage: una URL donde se puede encontrar más información acerca del software.

El siguiente párrafo es para el paquete binario que será construido a partir del código fuente. Si hay más de un paquete binario que se genere del código fuente debe haber un párrafo como el que describiremos a continuación para cada uno. De nuevo, vamos a ir línea por línea:

  • Package: Esto especifica el nombre del paquete deb pero no la firma ni la etiqueta de la arquitectura. Los nombres que aparezcan en Package y Source deben ser el mismo.
  • Architecture: La arquitectura para la cual será construido el paquete. Algunos ejemplos son:
    • all - El programa a empaquetar no depende de la arquitectura del sistema. Se refiere a programas hechos en lenguajes interpretados o independientes de la plataforma, como Python o Java. El resultado será un paquete binario cuyo nombre acabará en _all.deb.
    • any - El programa a empaquetar depende de la arquitectura del sistema y debe ser compilado en todas las arquitecturas compatibles. Habrá un archivo .deb para cada arquitectura (_i386.deb por ejemplo).

Se puede optar por una o más de un subconjunto de arquitecturas (i386, amd64, ppc, etc.) para indicar que el programa a empaquetar depende de una arquitectura concreta y no funciona para todas las arquitecturas soportadas por Ubuntu.

  • Depends: esto indica al sistema las dependencias del paquete deb resultante de todo el proceso, normalmente se resuelven basándose en las dependencias de construcción (Build-Depends) de modo que si por ejemplo indicamos allí programa-dev automáticamente el sistema sustituirá las variables ${shlibs:Depends} y/o ${misc:Depends} por programa (sin el -dev).

En algunas ocasiones (empaquetado de programas hechos en Python, Java y raras excepciones) es necesario indicar manualmente las dependencias del programa. Si se diera este caso lo más normal es añadirlas después de ${misc:Depends} respetando la estructura de comas.

  • Recommends: se usa para paquetes altamente recomendados y que normalmente se instalan junto al paquete. Algunos administradores de paquetes, por ejemplo aptitude, instalan automáticamente los paquetes que pongas en este campo.
  • Suggests: se usa para paquetes que son similares o útiles cuando el paquete (que crearemos) esté instalado.
  • Conflicts: se usa para paquetes que presentarán problemas con este paquete. Ambos no pueden estar instalados en un mismo sistema. Si uno se instala el otro se desinstalará y viceversa.
  • Description: aquí describiremos el programa, esto es lo que se verá cuando abras el archivo .deb con un programa como GDebi. La descripción de un paquete deb se basa en dos partes:
    • Un título de 60 letras que va directamente después de Description:.
    • Un texto de unas 47 letras (no estoy seguro si se pueden más) de largo con un espacio antes de cada línea. Los espacios entre párrafos se hacen mediante un punto.

[editar] copyright

El archivo copyright proporciona la información de derechos de autor. Generalmente, la información de copyright se encuentra en el archivo COPYING en el directorio principal del código fuente. Este archivo se debe incluir información como el nombre del empaquetador y del creador del paquete, la URL de donde conseguimos el código fuente, la licencia con el año del Copyright. Un plantilla del archivo podría ser:

This package was debianized by (Tu nombre) <tu_correo_electrónico> (Fecha)

It was downloaded from: (URL de la web de descarga del programa)

Upstream Author(s): (Nombre(s) y e-mail(s) del (los) autor(es) del programa)

Copyright: Copyright (C) {año(s)} por {autor(es)} {correo(s) electrónico(s)}

License: (Añade el texto de la licencia aquí. Para las licencias GNU basta con añadir la cabecera y
 enlazar al texto completo normalmente alojado en /usr/share/common-licenses.)

the Ubuntu packaging:
     Copyright (C) (año(s)) por (Tu nombre) <tu_correo_electrónico> (Fecha)
     released under {la licencia que quieras para tu paquete}

Como ya puedes imaginar hello se libera bajo la licencia GPL. En este caso es muy sencillo copiar el archivo copyright del paquete hello de Ubuntu:

cp ../../ubuntu/hello-debhelper-2.2/debian/copyright .

Nota que el archivo copyright del paquete hello de Ubuntu incluye la declaración de la licencia para el manual. Es importante que todos los archivos del código fuente estén declarados bajo una licencia.

Más información, consejos y soluciones están disponibles en la sección Copyright.

[editar] rules

El último archivo que vamos a necesitar es el rules. Este, prácticamente, hace todo el trabajo para crear nuestro paquete deb. Es un Makefile con instrucciones para compilar e instalar la aplicación, luego crear el archivo .deb a partir de los archivos instalados. También tiene instrucciones para revertir la compilación e instalación eliminando todos los archivos originales y así poder volver a disponer solo del código fuente.

Aquí tenemos una versión simplificada del rules creado por dh-make:

#!/usr/bin/make -f (-)

package = hello

CC = gcc
CFLAGS = -g -Wall

ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
  CFLAGS += -O2
endif

#export DH_VERBOSE=1

clean:
        dh_testdir
        dh_clean
        rm -f build
        -$(MAKE) -i distclean

install: build
        dh_clean
        dh_installdirs
        $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr \
                mandir=$(CURDIR)/debian/$(package)/usr/share/man \
                infodir=$(CURDIR)/debian/$(package)/usr/share/info \
                install

build:
         ./configure --prefix=/usr
         $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)"
         touch build

binary-indep: install
# There are no architecture-independent files to be uploaded
# generated by this package.  If there were any they would be
# made here.

binary-arch: install
        dh_testdir -a
        dh_testroot -a
        dh_installdocs -a NEWS
        dh_installchangelogs -a ChangeLog
        dh_strip -a
        dh_compress -a
        dh_fixperms -a
        dh_installdeb -a
        dh_shlibdeps -a
        dh_gencontrol -a
        dh_md5sums -a
        dh_builddeb -a

binary: binary-indep binary-arch

.PHONY: binary binary-arch binary-indep clean checkroot

Vamos a analizar el archivo con más detalle. La primera parte que puedes ver es la declaración de algunas variables:

package = hello

CC = gcc
CFLAGS = -g -Wall

ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
  CFLAGS += -O2
endif

#export DH_VERBOSE=1

En esta sección se exponen las banderas para el compilador y también se indica las opciones noopt para la información de depuración (debugging).

Ahora vamos a ver la sección build:

build:
         ./configure --prefix=/usr
         $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)"
         touch build

Estos comandos ejecutan el famoso ./configure con las variables adecuadas, luego ejecutan make y luego hacen un registro de la construcción para prevenir compilaciones múltiples erróneas.

Las siguientes instrucciones corresponden a la sección clean en la cual se ejecuta make -i distclean eliminando todos los archivos que se crean durante la construcción del paquete:

clean: 
        dh_testdir
        dh_clean
        rm -f build
        -$(MAKE) -i distclean

Lo próximo que veremos será unas instrucciones binary-indep vacías. Algunos paquetes se crean independientes de una arquitectura específica (como 32 o 64 bits) si no contienen archivos que necesiten de un compilador. La mayoría de los programas Python o de temas de escritorio son ejemplos de esto, sus paquetes terminan siempre en _all.deb.

hello es un programa escrito en C por lo que necesita de un compilador para funcionar y el resultado será un código binario diferente para cada plataforma, sus paquetes pueden terminar en _i386.deb o _amd64.deb principalmente. Para estos paquetes dependientes de una arquitectura se usa el campo binary-arch:

binary-arch: install 
        dh_testdir -a
        dh_testroot -a
        dh_installdocs -a NEWS
        dh_installchangelogs -a ChangeLog
        dh_strip -a
        dh_compress -a
        dh_fixperms -a
        dh_installdeb -a
        dh_shlibdeps -a
        dh_gencontrol -a
        dh_md5sums -a
        dh_builddeb -a

Aquí se ponen en funcionamiento una serie de scripts debhelper que crean nuestros paquetes deb. dh_testdir y dh_testroot hacen algunas comprobaciones de la estructura. dh_installdocs y dh_installchangelogs instala los archivos que especifiques en los archivos *.doc y *.changelog. dh_strip tomará la información de depuración (debugging symbols) y la apartará de la aplicación reduciendo drásticamente su tamaño. dh_compress ejecuta gzip (un compresor de consola) para comprimir alguna documentación. dh_shlibdeps añade las librerías dependientes al campo "Depends: ${shlibs:Depends}" en el archivo debian/control. Finalmente dh_builddeb construye nuestro archivo .deb. Tranquilo, no te debes preocupar mucho acerca de estos scripts, normalmente crean el paquete sin problemas.

Hay otro archivo, compat, el cual contiene el número de la versión de los scripts debhelper. De vez en cuando se publican nuevas versiones del debhelper, la versión actual es la 6 (en Ubuntu 8.04). Si se introduce una versión más antigua entonces los scripts debhelper puede que funcionen ligeramente diferente.

[editar] Construyendo el paquete

Ya estás listo para construir le paquete. Para ello simplemente ejecutaremos el comando:

debuild

Debuild comprobará primero si el paquete build-depends está instalado, luego usará dpkg-buildpackage para compilar, instalar y construir el o los paquetes deb usando las indicaciones del archivo debian/rules. Si todo está bien debuild intentará firmar digitalmente el o los paquetes con GPG, si te da un error de que no ha encontrado ninguna llave GPG significa que se ha creado correctamente el paquete deb pero tú no tienes una llave GPG con el mismo nombre y correo que el que usaste en el archivo debian/changelog.

Tu nuevo paquete debería estar en el directorio superior al código fuente. Échale un vistazo e instálalo:

cd ..
lesspipe *deb
sudo dpkg --install *.deb

[editar] Construyendo el paquete fuente

Ahora, una vez que hemos analizado los archivos del directorio debian/ en profundidad, podemos construir el paquete fuente (y también los paquetes binarios). Primero vamos a movernos al directorio principal en el que extrajimos el código fuente para construir el paquete usando debuild:

debuild -S

Este comando hace que el sistema tome como referencia el .orig.tar.gz para crear un archivo .dsc que contiene la descripción y el md5sum para el paquete fuente y un archivo .diff.gz en el cual se compara el código fuente comprimido (.orig.tar.gz) con el descomprimido en donde se halla el directorio debian/. Los archivos .dsc y *_source.changes usados para subir el paquete fuente serán firmados usando tu llave GPG.

La opción -S le dice al debuild que construya el paquete fuente usando los scripts dpkg-buildpackage y fakeroot para poder simular privilegios de administrador (root) cuando se construye el paquete.

Si no tienes una clave GPG configurada en el sistema recibirás un error del debuild. Puedes crear e instalar una clave GPG o usar las opciones -us -uc con debuild para no firmar digitalmente el paquete. Sin embargo, no serás capaz de subir tus paquetes a Ubuntu sin firmarlos. Para asegurarte de que debuild encuentre correctamente la clave GPG debes introducir las variables de entorno DEBFULLNAME y DEBEMAIL, en el script de inicio de tu intérprete de comandos (~/.bashrc en bash, por ejemplo), con el nombre y el cuenta de correo electrónico respectivamente que uses para la clave GPG y en el archivo debian/changelog.

Algunos usuarios han reportado que les fue imposible que debuild encontrara la clave GPG incluso después de introducir las variables. Si este fuera tu caso puedes probar con el comando:

debuild  -k <id_clave_GPG> 

Donde <id_clave_GPG> es el identificativo de tu clave GPG.

Para comprobar que el paquete se construya en un entorno limpio también podemos construir el paquete binario con pbuilder:

sudo pbuilder build ../*.dsc

Usando pbuilder podemos saber si las dependencias son correctas ya que este proporciona un entorno mínimo así que todas las dependencias quedarían determinadas por el archivo control.

Ahora podemos comprobar los errores comunes en el paquete fuente usando lintian:

cd ..
lintian -i *.dsc

[editar] Requisitos de paquetes nuevos para Ubuntu

Cuando un paquete fuente, que aún no existe, se sube a Ubuntu o se construye un nuevo paquete binario debe ser colocado en la lista NEW y tienen que ser revisado por un miembro del equipo del archivo de Ubuntu

[editar] Empaquetado
  • Lo más importante: Mirar los derechos de autor (copyright) y la información de la licencia antes de nada.
  • El paquete fuente y el paquete binario deben tener un nombre "sano": ni uno demasiado corto (como "editor") ni uno extremadamente largo y sin sentido (como "nuevo-cool-administrador")
  • debian/control y debian/rules deben construir paquetes con Architecture:, Build-Depends[-Indep]: correctos, y el archivo rules debe tener muy presente la relación (binary-arch vs. binary-indep).
  • Los scripts de mantenimiento del paquete no deben estropear demasiado el sistema
  • ...
[editar] Otros

[editar] Empaquetando con CDBS

...

[editar] Empaquetando módulos Python con CDBS

...

[editar] Empaquetado avanzado

...

[editar] Creando más de un paquete binario

...

[editar] Empaquetando librerías compartidas

Este documento explica qué son las bibliotecas compartidas, centrándose en símbolos exportados y explica algunos de los detalles de cómo empaquetarlos.


[editar] Librerías compartidas

...

[editar] Errores comunes

...

[editar] Archivos de ejemplo dh-make

...

[editar] Abusando de archivos

...

[editar] Cambiando el tarball original

...

[editar] Soluciones

...

[editar] Consejos

...

[editar] Información de Copyright

...

[editar] Paquetes de referencia

...

[editar] Sistema de parches

[editar] KDE

[editar] Archivos complementarios

[editar] Recetas

[editar] Apéndice

[editar] Fuentes

Herramientas personales