Guía de empaquetamiento/Completa

Uno o más colaboradores están trabajando actualmente en extender esta página. Es posible que, a causa de ello, haya lagunas de contenido, deficiencias de formato o texto en otros idiomas. Por favor, antes de realizar correcciones mayores o reescrituras, contacta con ellos en su página de usuario o en la página de discusión del artículo para poder coordinar la redacción.

Contenido 1 Introducción 1.1 Por dónde empezar 1.2 Requisitos 2 Empezando 2.1 Paquetes binarios y paquetes fuente 2.2 Herramientas de empaquetado 2.3 Empaquetador personal: pbuilder 3 Empaquetado básico 3.1 Empaquetando desde el código fuente 3.1.1 changelog 3.1.2 control 3.1.3 copyright 3.1.4 rules 4 Fuentes

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.

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.

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.

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:

• 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.

Empezando

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.

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.

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.

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.

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 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 preguntara que 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 librerías
• 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" "-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 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:

cd debian
rm *.ex *.EX

Para hello, tampoco necesitaras algunos archivos del directorio debian:

• README.Deban: 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.

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:

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

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

 * Aún 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

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.

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.

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 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).

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 estas 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.

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. 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.
  • 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 visitar esta web:

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

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 estas 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.

• 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/s. 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.
  • 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)

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 (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.

• 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.

• 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 abrás 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 linea. Los espacios entre párrafos se hacen mediante un punto.

copyright

Este archivo 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 .

Dese cuenta 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.

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 reevertir la compilación&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 especifica (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.

Fuentes

• https://wiki.ubuntu.com/PackagingGuide/Complete.