Continuando con los artículos referentes a Python, Glade, GtkBuilder, y a la publicación de un paquete deb en Launchpad, viene como hice el paquete. Realmente tenía que haberlo publicado antes que el de LauncPad, pero es que estoy tan emocionado (ya veremos lo que me dura la emoción).

Bueno, el procedimiento es el siquiente:

• Antes que nada instalamos todos los paquetes necesarios para esta operación:
  • sudo apt-get install build-essential automake gnupg lintian fakeroot pbuilder devscripts debhelper dh-make

• Creamos un directorio de trabajo:
  • mkdir arena
  • cd arena
• Creamos el directorio del paquete:
  • mkdir nombre_de_la_aplicacion-version (por ejemplo: tui-1.0)
• Empaquetamos todas las fuentes en archivo tar.gz. Simplemente se trata de esto, todas las fuentes, sin mas historias raras:
  • tar cvfz tnombre_de_la_aplicacion-version.tar.gz * (por ejemplo: tui-1.0.tar.gz)
• Creamos el directorio debian, para ello debemos estar dentro del directorio nombre_de_la_aplicacion-version y preparamos la plantilla sobre la que vamos a trabajar
  • export DEBEMAIL=correo@electronico.es
  • export DEBFULLNAME=»El nombre del mantenedor»
  • dh_make -f nombre_de_la_aplicacion-version.tar.gz -e
  • donde:
    • -c, –copyright <licencia> Usa el tipo de <licencia> para el archivo de copyright. <licencia puede ser gpl, gpl2, gpl3, lgpl, lgpl2 lgpl3, artistic, apache or bsd.
    • e, –email <dirección> Usa <dirección> como dirección de correo electrónico del campo Maintainer (desarrollador) para el archivo debian/control.
    • l, –library Establece automáticamente la clase del paquete a biblioteca, saltando la pregunta.
    • s, –single Establece automáticamente la clase del paquete binario único, saltando la pregunta.
    • i, –indep Establece automáticamente la clase del paquete a independiente de la arquitectura, saltando la pregunta.
    • m, –multi Establece automáticamente la clase del paquete a binario múltiple, saltando la pregunta.
• El siguiente paso es editar la plantilla de trabajo creada en el paso anterior. Para ello eliminamos todos los archivos excepto: changelog, compat, control, copyright, dirs, README.Debian, y rules
• Ahora se procede a configurar los archivos que nos han quedado uno a uno. En primer lugar changelog. Como es la primera versión quedará algo como este:

tui (1.0-1ubuntu1) karmic; urgency=low

* Initial release

-- atareao <email>  Mon, 26 Apr 2010 21:38:33 +0200

• con la utilidad «dch» se puede modificar adecuadamente la versión. Si se ejecuta «dch -i» se incrementa el número de versión.
• El siguiente archivo a editar es el de control, que tiene que quedar algo similar a éste:

Source: tui
Section: web
Priority: extra
Maintainer: mantenedor <email>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.8.1
Homepage: htt://www.atareao.es
Package: tui
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: An url shortener for Twitter

El primer párrafo da información sobre el código fuente del paquete. A continuación se detallan el resto de líneas:

• Source: el nombre del paquete de código fuente.
• Section: los repositorios apt son divididos en secciones para facilitar la navegación y categorización del software. Algunos ejemplos son: «main/x11″ o «universe/web».
• Priority: establece la importancia del paquete para los usuarios. Debería ser uno de los siguientes valores:
  • Required – los paquetes que son esenciales para que el sistema funcione correctamente. Si son eliminados es altamente probable que el sistema se dañe de una manera irrecuperable.
  • Important – el conjunto mínimo de paquetes para que el sistema sea usable. Eliminando estos paquetes no producira un daño irreparable en el sistema, pero generalmente son considerados como herramientas importantes sin las que cualquier instalación de Linux estaría incompleta. Nota: esto no incluye a paquetes como Emacs o incluso el sistema de X window.
  • Standard – autoexplicatorio.
  • Optional – en esencia, esta categoría es para paquetes no requeridos o para la mayor parte de los paquetes. Sin embargo, estos paquetes no deben entran en conflicto entre sí.
  • Extra – los paquetes que pueden entrar en conflicto con otros paquetes en una de las categorías superiores. Tambien es usado para paquetes especiables que solo es útil para personas que ya conocen el propósito del paquete.
• Maintainer: el nombre del mantenedor del paquete y su dirección de email.
• Standards-Version: la versión de la política de Debian a la que el paquete se adhiere. Tan facil como entrar la versión actual con apt-cache show debian-policy | grep Version.
• Build-Depends: uno de los campos mas importantes y a menudo la causa más frecuente de fallos en el código fuente, esta línea lista los paquetes binarios (con la versión si es necesario) que necesitan ser instalados para llevar a cabo la creación del paquete binario a partir del código fuente. Los paquetes que son esencialmente requeridos por build-essential no es necesario que sean incluidos. Nota: no necesitas una lista de paquetes que sean parte de build-essential. La lista de los paquetes de build-essential se encuentra en /usr/share/doc/build-essential/list.
• Homepage: una URL donde se encuentra más información del software.

El segundo párrafo es para el paquete binario que se construirá a partir del código fuente. Si existen múltiples paquetes binarios que son construidos desde el código fuente, habrá una sección para cada uno. La explicación para cada línea:

• Package: el nombre del paquete binario. En muchas ocasiones para programas simples, el paquete de código y el binario son idénticos.
• Architecture: las arquitecturas para las que el paquete binario sera construido. Algunos ejemplos son:
  • all – el código fuente no es dependiente de la arquitectura. Los programas que usan Python o otros lenguajes interpretados deberían usar esta opción. El paquete resultante terminará con _all.deb.
  • any – El código fuente es dependiente de la arquitectura y debería compilar en todas las arquitecturas soportadas. Habrá un archivo .deb para cada arquitectura (por ejemplo _i386.deb
  • Pueden listarse un subconjunto de arquitecturas (i386, amd64, ppc, etc.) para indicar que código fuente es dependiente de la arquitectura y los que no funcionara para todas las arquitecturas soportadas por Ubuntu.
• Depends: La lista de paquetes de la que el paquete binario depende para su funcionalidad. Para el ejemplo, vemos ${shlibs:Depends}, que es una variable usada por dpkg-shlibdeps para añadir los paquetes de bibliotecas compartidos necesarios por los binarios a Depends:. Mira la página del manual para dpkg-source(1) and dpkg-shlibdeps(1) si deseas más información. Generalmente para los paquetes de python podría ser «python2.5″ y «python-gtk2″
• Recommends: usado por los paquetes que son altamente recomendados y normalmente son instalados con el paquete. Algunos gestores de paquetes, más concretamente aptitude, automáticamente instalan los paquetes recomendados.
  Suggests: usado por paquete que son similares o útiles cuando el paquete es instalado.
• Conflicts: usado por paquetes que entrarán en conflicto con este paquete. Ambos no pueden ser instalados al mismo tiempo. Si uno de ellos es instalado, el otro será desinstalado.
• Description: la descripción corta (unos 60 caracteres y debe empezar en minúsculas) y larga son usadas por los gestores de paquetes. Nota que hay un espacio al principio de cada línea para la descripción larga (si se quiere dejar una línea en blanco se debe poner un sólo punto despues del espacio obligatorio).

Continuando con el proceso de editar todos los archivos, seguimos con el de copyright que debe quedar algo como éste:

This package was debianized by:
debianizar <email> on Mon, 26 Apr 2010 21:16:11 +0200
It was downloaded from:
Inicio

Upstream Author(s):
author <email>
Copyright:
<Copyright (C) 2010 author<email>
License:
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program.  If not, see <https://www.gnu.org/licenses/>.
On Debian systems, the complete text of the GNU General
Public License version 3 can be found in `/usr/share/common-licenses/GPL-3`.
The Debian packaging is:
Copyright (C) 2010 debianizer <email>
and is licensed under the GPL version 3, see above.
# Please also look if there are files or directories which have a
# different copyright/license attached and list them here.

El siguiente paso y algo más complicado que este es la edición del archivo rules, donde es necesario algo de trabajo mental. El primer problema con el que me encontré fueron los separadores. ¿Qué? ¿qué son separadores?, simplemente es la forma en que están tabulados los archivos. Los archivos make están tabulados (no vale sustituir tabuladores por espacio). Sino se tabulan, lo más seguro es que en la ejecución del make (o debian/rules) apareciera un error similar a este: «makefile:2: *** falta un separador. Alto»
También te puede dar errores si mezclas tabuladores con espacios, así que cuidado al escribir el debian/rules.

En este archivo lo que hay que manipular es la parte de la instalación, en mi caso ha sido la siguiente:

#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
configure: configure-stamp
configure-stamp:
dh_testdir
# Add here commands to configure the package.
touch configure-stamp
build: build-stamp
build-stamp: configure-stamp
dh_testdir
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Build the sctructure
mkdir -p ${CURDIR}/debian/tui
mkdir -p ${CURDIR}/debian/tui/usr
mkdir -p ${CURDIR}/debian/tui/usr/share
mkdir -p ${CURDIR}/debian/tui/usr/share/applications
mkdir -p ${CURDIR}/debian/tui/usr/share/pixmaps
mkdir -p ${CURDIR}/debian/tui/usr/share/tui
# Copy files
cp *.py ${CURDIR}/debian/tui/usr/share/tui/
cp *.glade ${CURDIR}/debian/tui/usr/share/tui/
cp *.png ${CURDIR}/debian/tui/usr/share/tui/
cp tui.png ${CURDIR}/debian/tui/usr/share/pixmaps/
cp tui.desktop ${CURDIR}/debian/tui/usr/share/applications/
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs
dh_installexamples
# dh_install
# dh_installmenu
# dh_installdebconf
# dh_installlogrotate
# dh_installemacsen
# dh_installpam
# dh_installmime
# dh_python
# dh_installinit
# dh_installcron
# dh_installinfo
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
# dh_perl
# dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure

usr/bin
usr/share/tui
usr/share/applications
usr/share/pixmaps

debuild -S -kGPGKEY