[Tutorial] Crear paquetes .deb desde las fuentes Ubuntu Kubuntu Xubuntu 7.04 Debian GNU/Linux

Hola humanistas amigos, interesados y otros;

En esta oportunidad, para los que no pudieron concurrir, traigo conmigo la charla/tutorial que ofreció el pasado Domingo 26 de Agosto, a las 17:00, Margarita Manterola, una de las Debian Developer de Argentina.

La charla fué en el canal #debian-ar, de irc.oftc.net. Sin más detalles, pasemos al log.

- Vale la aclaración, formatee este log para una mejor comprensión, ordenando las preguntas y respuestas que me parecieron importantes.-

---

Bueno, ya es casi la hora. En seguida empiezo. Les pido que traten de sólo hablar on-topic, y sólo si tienen una pregunta para hacer, si?

Este tutorial está dirigido a todo aquél que nunca haya hecho un paquete de Debian, o a quienes ya hayan hecho alguno, pero quieran practicar un poco más, reforzando algunos conceptos que son importantes a la hora de generar un paquete limpio y estable.

Por favor, si les van surgiendo preguntas para hacer, háganlas en el momento, y por este mismo canal. Me interesa que me vayan siguiendo, y me vayan diciendo si hay algo que no se entiende. Si voy muy rápido o muy lento, también avísenme. El tutorial es bastante largo, así que traten de seguirlo mientras lo voy dando. También me pueden hacer comentarios por privado, para no hacer tanto “ruido”.

Lo primero que tienen que hacer es instalarse los paquetes que van a hacer falta para la compilación del programa que vamos a empaquetar. Les paso la línea de apt:

$ sudo aptitude install build-essential devscripts dh-make fakeroot valgrind libqt3-mt-dev libstdc++6-dev

Los primeros 4 son estándar y sirven para cualquier paquete que tengan que empaquetar. Los otros 2 son las dependencias de compilación del paquete que vamos a armar. Mientras se van bajando los paquetes (es probable que lleve un rato), vamos avanzando con la charla.

Antes que nada, una aclaración con respecto a Debian/Ubuntu: los paquetes para Debian y Ubuntu se arman de la misma manera, con las mismas herramientas. Es posible que un paquete armado para Debian funcione en Ubuntu y viceversa. Si no sucede así, es por un problema de versiones de las dependencias, y no por una falencia en el paquete.

La diferencia entre Debian y Ubuntu es el procedimiento para agregar paquetes al archivo oficial de la distribución. Yo me voy a nombrar los procedimientos para Debian, pero esto no quiere decir que el resto del tutorial no les sirva a quienes vayan a querer mantener paquetes en Ubuntu.

Es posible, y hasta yo diría que deseable, mantener un paquete tanto en Debian como en Ubuntu, no son trabajos excluyentes. A partir de ahora, siempre que diga “un paquete de Debian” me refiero a un paquete de Debian o de Ubuntu según su preferencia.

Hay básicamente dos situaciones en las cuales uno se pone armar un paquete de Debian. La primera es cuando uno está aburrido y dice “hoy tengo ganas de empaquetar algo”, la segunda es cuando uno encuentra un programa que está bueno y no está empaquetado.

En el primer caso, si uno no sabe qué empaquetar, se pueden buscar ideas en el listado de paquetes en adopción: http://www.debian.org/devel/wnpp/work_needing o bien en el listado de paquetes solicitados: http://www.debian.org/devel/wnpp/requested. Y en Ubuntu: https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging

En Debian: SIEMPRE antes de subir un paquete hay que hacer un “ITP” que quiere decir “Intend To Package” o un “ITA” (Intend to Adopt) en el caso en que estuvieran adoptando un paquete existente. Cuando se deciden a hacerse cargo de un paquete , deben cambiarle el título a la solicitud, para que quede claro que ustedes van a empaquetarlo.

Es decir, deben reemplazar “RFP” (Request For Package) por “ITP”, o “O” (Orphaned) o “RFA” (Request for Adoption) por “ITA”. Para ello deben usar el comando “retitle”, según se explica en http://www.debian.org/devel/wnpp y en http://www.debian.org/Bugs/server-control

Pregunta:
Generalmente se tiende a empaquetar usando los paquetes de una rama en particular? stable, testing, sid?.

Respuesta:
Generalmente unstable. En el caso de ubuntu, la distro más nueva (gutsy ahora)

En Ubuntu: empezar un paquete nuevo, oficial, es un poquito más complicado, pero básicamente hay que seguir las instrucciones de https://wiki.ubuntu.com/MOTU/Packages/REVU

Aclaración de un colaborador:
Vale aclarar que en Gutsy cierra en 4 dias la fecha para que entren paquetes nuevos, y se reabrira para la siguiente version a finales de Octubre)

Continuamos,

Es por cómo funciona el traslado de un paquete de una distribución a otra. Primero se suben a unstable y de ahí pasan a testing. En Ubuntu, subís a gutsy, para cuando se haga el release

Si se trata, en cambio, del segundo caso, es decir que encontraron un programa interesante que no está empaquetado, es importante que se fijen si ya hay otra persona trabajando en armar el paquete, o si hubo alguien que lo solicitara.

Comenzando un nuevo paquete

En Debian: para ello utilizan la lista de “Futuros Paquetes” (http://www.debian.org/devel/wnpp/prospective) y revisan que el paquete no se encuentre en el listado como “ITP”, o, si se encuentra como “RFP” le cambian el nombre como antes.

En Ubuntu: primero deben fijarse si ya está para Debian, porque en muchos casos simplemente se hace un “sync” con Debian. Y en caso en que no esté, generar un nuevo bug, como se explica en: https://wiki.ubuntu.com/MOTU/Packages/New

Descargando el programa

En particular, hoy vamos a empaquetar una herramienta llamada Valkyrie, que es una interfaz gráfica para Valgrind. El pedido de paquete para Debian está en: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372268

Ahora vamos a empezar con el empaquetamiento. Lo ideal sería que para trabajar con los paquetes tengan un directorio “debian/” o “src/debian” o “sources/debian” en su home, y el archivo con el código fuente del paquete lo guarden en ese directorio. (O ubuntu, según corresponda)

El programa lo bajan de: http://www.open-works.co.uk/projects/valkyrie.html
Para ver el contenido del archivo pueden hacer: tar -tjvf archivo.tar.bz2 y para descomprimirlo, tar -xjvf archivo.tar.bz2

Mientras bajan el archivo y lo descomprimen, vamos a configurar unas variables de entorno, que nos hacen falta ahora y nos van a servir en el futuro.
Esto lo pueden hacer ahora desde la línea de comandos, pero es una buena idea dejar estas variables de entorno en los archivos .bashrc, .zshenv, etc, de modo que esten seteadas la proxima vez que vayan a armar un .deb
Lo que tienen que configurar es: “export DEBEMAIL=tu@email.com” y “export DEBFULLNAME=”"Tu nombre”"”. Una vez que tengan esas variables seteadas, ya podemos proceder a crear el paquete. También sería posible pasar estos valores por parámetro, pero es preferible tener las variables seteadas, ya que en general el mail y el nombre propio no cambian

En todos los unix, para ver la lista de variables lo ves con set. Pero pueden ser muchas, si querés ver una en particular, hacelo con echo $VARIABLE.

Lo primero que hay que hacer es renombrar el archivo tar.bz2 al nombre requerido por las herramientas. El nombre debe ser paquete_version.orig.tar.gz, en este caso, el paquete se llama “valkyrie” y la versión es “1.2.0″. Pero hay un problema: es un bz2 y no un gz. Actualmente las herramientas soportan el formato bz2, pero aún no se aceptan paquetes cuyo código fuente esté en bz2

De modo que hay que desempaquetarlo, y luego generar el tar.gz correspondiente.

Así: “tar -xjf valkyrie-1.2.0.tar.bz2″ (si no lo habían hecho ya) y luego: “tar -czf valkyrie_1.2.0.orig.tar.gz valkyrie-1.2.0″. Así ya tenemos el archivo correcto.

Pregunta:
Sabiendo eso, para qué lo ponen para descarga en bz2? más compresión?

Respuesta:
Sí, en el futuro se va a poder usar bz2.

Usando dh_make

Para armar el paquete vamos a usar una herramienta especialmente creada para ese propósito, llamada dh_make. Esta herramienta prepara un “template” de paquete que después tendremos que modificar. Para que dh_make funcione, es necesario que el directorio donde se encuentra el código fuente tenga el nombre estándar “paquete-version”. En este caso, valkyrie-1.2.0

Así que hagan: “cd valkyrie-1.2.0″ y luego “dh_make”
Al ejecutarlo, les va a preguntar el tipo de paquete que desean crear. En este caso, el tipo de paquete es “single binary”, ya que nuestro paquete generará un solo .deb. Luego pide confirmar los datos y crea el paquete. Termina haciendo una advertencia con respecto a los archivos de Makefile, que vamos tener en cuenta un poco más adelante.

Pregunta:
La licencia dice Blank ¿está bien?

Respuesta:
Sí, es correcto.

Continuamos,

Luego de ejecutar “dh_make”, al hacer un ls del directorio actual (valkyrie-1.2.0) van a ver que aparece un directorio “debian/” que antes no estaba.

dh_make es un comando genérico que lo que hace es generar un directorio lleno de archivos, no todos esos archivos nos van a servir, una gran mayoría los vamos a borrar. Están ahí porque de esa manera, cualquiera sea el tipo de paquete que vayamos a armar, ya tenemos cubierto el espectro de archivos que vamos a necesitar.

Pregunta:
¿Puede ser que el dh_make cree el tar.gz?

Respuesta:
tendría que decir “Skipping creating ../valkyrie_1.2.0.orig.tar.gz”. Si te dice que lo creó, es que el nombre del tar.gz que hiciste no estaba del todo bien.

Continuamos,

Directorio /debian

Entren en el directorio /debian y fíjense un poco los archivos que están ahí. Yo les voy a ir diciendo qué archivos borrar.
*) cron.d.ex es un ejemplo para un paquete que tenga que agregar una tarea al cron, el nuestro no tiene así que se va.

*) emacsen-* son archivos relacionados con emacs, tampoco nos interesan.

*) init.d.ex es un ejemplo para un paquete que tenga que tener un script de inicio, el nuestro no tiene, así que se va.

*) valkyrie-default.ex es un ejemplo de un archivo de defaults, está relacionado con los scripts de inicio, tampoco nos hace falta, así que se va.

*) valkyrie-doc-base.EX es otro ejemplo, que nos permitiría añadir la documentación a la base de datos general de documentos, pero no tenemos una documentacion importante, así que se va.

Pregunta:
¿Cómo sabemos si la documentacion es importante o no?

Respuesta:
Hay que analizar qué es lo que trae el paquete. Ese paso lo saltée, para que no se haga eterno el tutorial. Este paquete trae, en el directorio doc/, unos htmls con un manual, pero son bastante básicos, por lo que no ameritan ser agregados a la base de datos de documentación.

Continuamos,

Con respecto a la página man, todo paquete de Debian debe tener su página man, el sistema nos permite que “el fuente” esté en uno de tres formatos posibles: groff (es el 1.ex), sgml y xml. Groff es el formato original de las páginas man, mientras que sgml y xml son lenguajes para los cuales existen conversores (que los transforman a groff).

*) Escribir una página man lleva tiempo, así que para este tutorial simplemente renombramos la manpage.1.ex a valkyrie.1 (valkyrie porque es el nombre del ejecutable generado y 1 porque es una aplicación que se encuentra en la seccion 1 de las páginas man). Copiamos el mismo archivo a vk_logmerge.1 (otro ejecutable que también genera el paquete) y borramos los otros dos ejemplos (manpage.sgml.ex, manpage.xml.ex).

*) postinst.ex, prerm.ex, preinst.ex y postrm.ex son los “maintainer scripts” que se ejecutan cuando el paquete se instala o se desinstala. En nuestro caso, nuestro paquete no va a hacer nada loco, con lo cual no nos hace falta ningún maintainer script adicional.

*) README.Debian es para colocar mensajes específicos de Debian que uno le quiera dar a los usuarios. En este caso, se trata de un paquete bastante sencillo, por lo que no hay ningún mensaje importante para dar. Se borra.

*) menu.ex es un ejemplo que _si_ vamos a usar. Lo renombramos a “menu”. De la misma manera con watch.ex, lo renombramos a “watch”.

Haciendo un ls, los archivos que quedaron son: changelog compat control copyright dirs docs menu rules valkyrie.1 vk_logmerge.1 watch

Estos son, para nuestro paquete, los archivos importantes. Vamos a ver en detalle de qué se trata cada uno. Cada vez que nombre un archivo, por favor ábranlo y mírenlo.

Los conffiles son archivos de configuración generales del sistema.

debian/changelog

Abrimos: debian/changelog
El changelog es un archivo cortito (por ahora), pero tiene bastante información. En la primera línea dice: “valkyrie (1.2.0-1) unstable; urgency=low”. En el caso de que estén usando Ubuntu, puede ser que diga el nombre de la distro… me lo confirman?

Respuestas de los concurrentes:

• Estoy usando dapper, y dice unstable, tambien
• En mi caso no, no dice nada
• En feisty dice unestable

Comentario del disetante:
En ese caso, deberían cambiarlo a mano.

Lo primero es el nombre del paquete. Lo segundo es la version, donde 1.2.0 es la versión del programa, y -1 es la revisión de Debian. Ustedes pueden tener varias revisiones de Debian para una misma versión del programa. Se irán numerando -2, -3, etc.

“unstable” indica que estamos preparando este paquete para subirlo a “unstable” que es el camino normal de los paquetes en Debian. En Ubuntu va directamente el nombre de la distribución para la que se esté preparando el paquete. O sea, deberían borrar “unstable” y poner “feisty”, “gutsy” o similar.

Comentario de un colaborador:
-Para meter el paquete en Ubuntu, ahí deberá decir la versión, ej. gutsy-

Continuamos,

“urgency=low” indica que es un paquete con baja urgencia, es decir que una vez subido a unstable, no pasará a testing hasta después de 10 días, si es que no se le reporta ningún bug crítico. (No sé qué efecto tiene el urgency en Ubuntu)

En la otra línea nos dice:

* Initial release (Closes: #nnnn)

Esto se refiere a lo que habíamos hablado antes. Lo que hay que hacer es reemplazar el número “nnnn” por el número de bug asignado al ITP del paquete. En este caso, el ITP que tiene el paquete es #372268.

Pregunta:
En Ubuntu iría el número de bug de Ubuntu?

Respuesta:
si, va LP #NNNN

Pregunta:
¿y cual sería ese número en ubuntu?

Donde LP #NNN es el bug en Launchpad que corresponde al paquete.

Respuesta:
Lo del final es un comentario, que hay que borrar. De manera que la línea del changelog nos queda: * Initial release. (Closes: #372268)

Comentario de un colaborador:
-Tengo entendido que parsea directamente LP #NNNN-

Pregunta:
¿Lo de arriba también se borra?

Respuesta:
Lo de arriba y lo de abajo queda. Yo decía la línea del centro.

debian/control

Abrimos: debian/control, “control” es otro de los archivos importantes del directorio debian/, ya que contiene la descripción del archivo, las dependencias, el nombre del responsable del paquete y otra información relevante.

La primera línea: “Source: valkyrie” indica cómo se llama el paquete “fuente”. En nuestro caso, como le pusimos “single binary” el fuente se llama igual que el binario, pero para los paquetes que generan más de un binario, esto no es así. No vamos a ver multi-binarios en este tutorial, cualquier cosa me preguntan.

La siguiente línea: “Section: unknown” indica en qué sección de los repositorios de Debian se encuentra el paquete. Como se trata de un aplicación de desarrollo, va en la sección “devel”. La lista completa de secciones la pueden ver en: http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-subsections

Comentario de un colaborador:
Algunas cosas en debian/control son distintas en Ubuntu ya que se mantienen los paquetes en equipos, y no individualmente.

Continuamos,

En este caso, para saber en qué sección ponerlo, me fije en qué sección iba el valgrind, ya que esto es una interfaz gráfica para Valgrind).

A continuación viene la prioridad, que indica qué tan importante es el paquete. Como es una herramienta de debugging, no muy importante, lo dejamos en “extra”. Luego viene el maintainer, y están los datos que le pusimos en las variables de entorno.

Pregunta:
“Hay gente que verifica que los paquetes creados por terceros estén bien construídos?

Respuesta:
Si, antes de entrar al archivo tienen que pasar por un control (en el caso de debian es por parte del ftp-master), y además hay equipos de QA que revisan todos los paquetes, una vez que ya estan en el archivo.

Comentarios de colaboradores:
En Ubuntu el maintainer es el equipo de LP, y se agrega un ítem adicional que es XSBC-Original.

Solo del Debian Developer pueden subir paquetes, el resto tiene que pedirle a un Debian Developer que se lo suba por él. (s/del/los/).

Continuamos,

A continuación, el campo “Build-depends”. Hay que modificarlo, y es importante, ya que si no lo hacemos así, el paquete no se va a poder compilar automáticamente. Hay que indicar qué paquetes tienen que estar instalados para poder compilar.

Valkyrie es un programa que usa las bibliotecas QT, es necesario indicar, entonces “libqt3-mt-dev”, que es el paquete que incluye a todas las dependencias de qt. Por otro lado, no nos van a hacer falta los autotools, así que pueden borrar lo de “autotools-dev”.

Podemos ponerlo a partir de una versión en particular (como está ya puesto para debhelper) o simplemente el nombre del paquete. En este caso dejamos solamente el nombre del paquete.

Entonces, la línea de Build-Depends queda en: Build-Depends: debhelper (>= 5), libqt3-mt-dev
El “Standards-Version” es la versión del Debian Policy bajo la cual está armado el paquete. Esta variable hay que ir manteniéndola actualizada, a medida que se actualiza el Policy, fijándose que el paquete cumpla con los nuevos requisitos. En este caso no hay que hacer nada.

Ya pasamos al paquete binario. La siguiente línea que nos interesa dice “Architecture: any”, esta línea nos indica que nuestro paquete se puede compilar para todas las arquitecturas. En general lo vamos a dejar así, aunque solamente lo compilemos en i386 (o amd64), para el resto de las arquitecturas va a ser compilado a través del sistema de buildds de Debian/Ubuntu.

Pregunta:
“Las policies están en el sitio de debian, supongo”

Respuesta:
Si, y también están disponibles como paquetes que uno puede consultar, sin estar conectado. http://www.debian.org/doc/debian-policy/

-debian-policy es el paquete si lo quieren instalar-

Continuamos,

Otra opción es Architecture: all, es el caso de las aplicaciones que no hace falta compilar. Por ejemplo: scripts (python, perl, php), paquetes que contienen documentación, o imágenes, etc. En ese caso el paquete no es compilado por los buildds, sino que el paquete que subamos es el que todos van a instalar.

Pregunta:
Cuando se decide que no es compilable en alguna arquitectura?

Respuesta:
Puede suceder que requiera ciertas características específicas de algunos procesadores o que tenga disponibles bibliotecas / entornos que en esa arquitectura no están. “prueba y error”

Pregunta:
Podes contarnos algo sobre el sistema de buildds de Debian/Ubuntu? cómo funciona?

Respuesta:
Es medio mágico. Subís el paquete y automáticamente se compila para todas las arquitecturas disponibles; En nuestro caso lo dejamos en Any.

Comentario del colaborador:

Cuando suben un paquete, aquí pueden ver como compilo: http://people.debian.org/~igloo/status.php?packages=exifprobe

Pregunta:
¿Teóricamente el paquete no está ya compilado?

Respuesta:
Si, pero solo para tu arquitectura; No es lo mismo i386, que amd64, que powerpc, que sparc.

Pregunta:
Por eso, subo algo compilado y ese “server” compila para el resto de las arquitecturas? no me cierra.

Respuesta:
No es un server, es una red de servers.

Comentario del colaborador:
Subís el código fuente también.

Continuamos,

A continuación vienen las dependencias. En esa línea hay unas variables “mágicas” que van a ser completadas automáticamente cuando generemos el paquete. Estas variables se completan haciendo un “ldd” del archivo compilado. En este caso el ldd no es suficiente, ya que este programa requiere del valgrind para funcionar, tenemos que agregar “valgrind” en esa línea.
Quedaría: Depends: valgrind, ${shlibsepends}, ${miscepends}
Y finalmente viene la descripción. La descripción debe estar en inglés y se compone de dos partes. La primera es únicamente una línea, que, en general, no debe empezar con mayúscula ni nombrar al paquete, y no debe terminar con “.”, debe ser una pequeña explicación acerca del programa.

Consulta del concurrente:
Me aparecen caritas en esa linea.

Respuesta:
Simplemente agregar un valgrind delante.

Por ejemplo “Description: graphical user interface for valgrind 3.X -sin < >-

Continuamos,

Y luego viene la descripción larga, que debe empezar dónde está marcado, dejando un espacio. Esta descripción puede tener varias líneas, y la idea es que dé una idea más amplia del contenido del paquete. En general, comienza con el nombre del paquete.

Si se quiere dejar líneas en blanco, se pone una línea que contiene un ” .” (espacio punto). Para escribir la descripción, cuando uno no está muy inspirado, se suele mirar el README o la web. En particular, yo lo rellené con el texto que está en: http://www.open-works.co.uk/projects/valkyrie.html, abajo del nombre.

Recuerden poner ” .” en las líneas en blanco.

Pregunta:
Comillas punto comillas?

Respuesta:
Espacio punto.

Pregunta:
Borramos la long description?

Respuesta:
Si, y pega la que está en la web (o poné lo que quieras)

Al final de todo, se agrega una línea que diga ” Homepage: ” y la URL correspondiente.

Pregunta:
¿No te dejan subir paquetes sin description y url no?

Respuesta:
Es necesario completar esos campos.

Pregunta:
¿Al final de la descripción o como otro campo?

Respuesta:
Es parte de la descripción, algún día será un campo aparte, pero por ahora no.

Pregunta:
El homepage también con espacio adelante, no?

Respuesta:
Si, toda la descripción larga lleva un espacio adelante.

Continuamos,

Abrimos: copyright

debian/copyright

En este archivo hay varias cosas para completar, que creo que son bastante claras. Donde dice “It was downloaded from” va la URL de donde lo bajamos.

Pregunta:
Pregunta sobre la descripcion: va cortado a 80 columnas? menos? todo en un renglon con un al final? va el enlace directo?

Respuesta:
Va cortado a 80 columnas, si. Lo importante es que empiece con espacio. El al final no importa. Sí, va el enlace.

Continuamos,

Donde dice “Upstream Author(s):” va el nombre del autor o autores del programa (hay que sacar los paréntesis y dejar Author o Authors según corresponda). En general esta información se encuentra en el archivo AUTHORS. En este caso son: Donna Robinson y Cerion Armour-Brown.

Donde dice “Copyright”, van los años y los dueños del Copyright. Esto, en general, está especificado en los encabezados de los archivos fuente. Lo que hay que hacer, siempre que uno prepara un paquete, es revisar los encabezados y ver si todos tienen el mismo Copyright, o no. En este caso es fácil, porque todos son prácticamente iguales. La línea de copyright es: “Copyright (c) 2000-2006, OpenWorks LLP “

Finalmente, hay que especificar la licencia. Obviamente, antes de ponerse a empaquetar, uno se tiene que fijar la licencia y ver que sea una licencia válida, que se va a poder distribuir, y en lo posible que sea libre, de manera que pueda ir en la sección “main” de Debian/Ubuntu.

Pregunta:
Si no estan los emails de los autores no hay problema?

Respuesta:
No. Es medio simbólico lo de los autores. Es más importante la línea del copyright.

Continuamos,

Este programa indica en sus encabezados que es un programa GPL v2. Por lo cual ponemos una línea como la siguiente: “This program is released under the terms of the GNU GPL v.2″. Y en la línea de abajo: “In Debian Systems, you can find a copy of the GNU GPL v2 at: /usr/share/common-licenses/GPL-2″.

Pregunta:
¿Puede ser que me aparezca “License:” en vez de “Copyright:”?

Respuesta:
Es posible, evidentemente tenemos versiones distintas de dh_make pero License no es lo mismo que Copyright; Tiene que haber una línea de “Authors”, una de “Copyright” y una de “License”.

Comentario del concurrente:
Yo tengo donwloaded from, copyright holder y license

Respuesta:
Si no existe alguno de los campos, lo agregan.

Continuamos,

Los autores son los que escribieron el software, los copyright holders son los que tienen los derechos sobre el software, y la licencia son los términos bajo los cuales se distribuye el software.

Pregunta:
Suponiendo que quiero hacer un paquete de algo que no tiene licencia, ni autores, ni nada. no debería hacerlo o hay casos especiales?

Respuesta:
Podes hacerlo, pero no lo vas poder poner en Debian ni Ubuntu. Lo podes tener en un repositorio personal, tuyo.

Pero no porque no tenga licencia, me parece.

Todo lo que no tenga licencia, o su licencia no permita redistribución no se puede poner en los repositorios oficiales. Vos, en tu vida privada, podés hacer lo que quieras.

En el caso en el que la licencia no estuviera incluida en /usr/share/common-licenses/ (Artistic, BSD, GPL, GPL-2, LGPL, LGPL-2, LGPL-2.1), hay que incluirla completa, no alcanza con poner el nombre.

Pregunta:
Ejemplo sería el rar que está en un dep distinto?

Respuesta del colaborador:
No, porque no es libre el formato de compresión al igual que mp3 y esos codecs.

Pregunta:
Por las dudas, en “Upstream Author” no vamos nosotros, no?

Respuesta:
No. “upstream” son los autores originales del software. Los que lo escribieron. Vos sólo serías el maintainer.

Continuamos,

Si tienen una de las versiones nuevas de dh_make, después de la licencia viene la licencia del empaquetamiento, esto es algo que es relativamente nuevo, hasta hace poco dh_make no lo sugería y casi nadie lo ponía. En general, vamos a seguir la sugerencia de dh_make y licenciarlo GPL.

Si no aparece, lo pueden escribir ustedes “The Debian packaging is (C) 2007, and is licensed under the GPL, see `/usr/share/common-licenses/GPL”".”

Pregunta:
En license, entonces, se pone sólo el nombre de la licencia?

Respuesta:
Si es una de las “common-licences” si. Si es una licencia rara, hay que ponerla completa.

Pregunta:
¿Qué sentido tiene licenciar mi “empaquetamiento”?

Respuesta:
Depende de cuántro trabajo hayas hecho en el paquete. Hay veces en que es bastante laburo, y en ese caso es importante licenciarlo para que otros puedan modificarlo y redistribuirlo, legalmente.

Pregunta:
Tenía pensado que funcionaba como la wiki ¿Todo lo que hagas para debian queda en una licencia libre para que puedas modificar?

Respuesta:
Digamos que se asume que todos los empaquetadores para Debian/Ubuntu están empaquetando con una licencia libre, pero es mejor dejarlo dicho explícitamente; En general, conviene que la licencia sea la misma que la del paquete para evitar problemas.

Continuamos, terminamos con copyright.

debian/rules

Abrimos: debian/rules

Este archivo viene a ser una suerte de Makefile, pero especial de Debian. Si lo abren van a ver que adentro hay montones de líneas que dice “dh_…” estas son las instrucciones de Debhelper para hacer una u otra cosa.

Debhelper es un conjunto de comandos (todos los dh_*), que ayudan a generar un paquete de Debian. No es obligatorio utilizarlo, pero en general es una ayuda importante.

Otro comando que se puede utilizar para hacer paquetes de Debian es “cdbs”, hay gente que lo adora y gente que lo odia. En este tutorial no lo vamos a ver.

Algunas de las líneas en debian/rules están comentadas y otras no. Algunas las vamos a descomentar, y las que no usemos las vamos a terminar borrando.

Al igual que lo que dije antes de los archivos que genera dh_make, acá hay muchas reglas, para que sea lo más flexible posible, después uno se queda con lo que necesita.

Ahora vamos a hacerle un par de cambios al debian/rules. Muchas veces esto es lo que más tiempo lleva, porque uno se tiene que fijar cómo compila el programa, qué problemas tiene, y demás. Yo ese trabajo lo hice anticipadamente, pero si lo estuvieran haciendo ustedes, seguramente les llevaría un rato.

Pregunta:
¿Si no modifico nada, deberia andar bien no?

Respuesta:
Depende del paquete. En este caso, no.

Si tenés suerte y te toca un programa que está bien hecho, si.

Continuamos,

En la línea que dice ./configure hay que agregar “–with-Qt-dir=/usr/share/qt3″ (en la misma línea, sin que se corte). Para que el programa encuentre donde están los datos de Qt.

Yo lo agregué justo antes de LDFLAGS, pero lo pueden agregar en cualquier lado.

Además, vamos a borrar todo lo que está entre el ifneq “$(wildcard /usr/share/misc/config.sub)”, hasta antes del configure, ya que no hace falta. (son 6 líneas en total)

Fíjese la línea que dice ./configure dentro del target “config.status”

Pregunta:
¿Lo que hay que borrar es desde ifneq hasta en el endif?

Respuesta:
Si, pero atención que hay más de un ifneq. Los que dicen lo de config.sub y config.guess

todo el paquete.

Más abajo, casi al final, encontramos la regla que genera el paquete (binary-arch). En esa regla hay muchas líneas comentadas. La única que tenemos que descomentar es dh_installmenu, las otras que están comentadas las podemos sacar. Son todas reglas optativas que no vamos a usar.
También podemos borrar: dh_installexamples y dh_link, que tampoco vamos a usar.

Parches

Bien, lo que nos falta ahora antes de poder compilar es hacerle unos arreglitos al código fuente.
La mayoría de los paquetes que uno vaya a hacer van a tener sus “cosas” que hay que arreglar. No es para espantarse, esto se debe a que el autor del programa lo compiló en su sistema, con su entorno, que no necesariamente es el mismo que el nuestro.

Este programa tiene unos pequeños bugs en sus Makefiles, que tenemos que corregir. En los 3 casos que vamos a ver corregiremos tanto el Makefile.am como el Makefile.in. En realidad con el .in sería suficiente, pero por una cuestión de prolijidad, corregimos los dos.

Pregunta:
¿Borramos la dependencia al autotools? ¿como puede seguir usando el .in?

Respuesta:
Si, porque no vamos a regenerar. Al revés, el .in es el que usa el ./configure, el .am es el que usan los autotools. Es decir, el .am no hace falta arreglarlo, lo arreglamos sólo por si en algún momento tenemos que regenerar.

Continuamos,

Vayan para atrás, al directorio padre: valkyrie-1.2.0

*) valkyrie/Makefile.am: en la línea 145 dice QTDIR, debería decir QT_DIR

*) valkyrie/Makefile.in: misma corrección línea 346

*) doc/Makefile.am: en la línea 3 dice “docdir = $(prefix)/doc/”, debería decir “docdir = $(prefix)/share/doc/valkyrie/manual/”

Pregunta:
Mi archivo es mucho más corto, solo tiene 20 lineas ¿es correcto?

Respuesta:
No estás mirando el archivo que corresponde; fijate que es el Makefile.am/in del directorio valkyrie, no el del directorio en el que estás parado.

Continuamos,

*) doc/Makefile.in: misma corrección, línea 161
doc/images/Makefile.am: en la línea 3 dice “docdir = $(prefix)/doc/images”, debería decir “docdir = $(prefix)/share/doc/valkyrie/manual/images”

*) doc/images/Makefile.in: misma corrección línea 152

En este caso los arreglos los estamos haciendo directamente sobre el código fuente. Una manera más limpia sería hacerlos con “dpatch” y guardarlos como parches separados del código, pero eso ya escapa al nivel de este tutorial.

Pregunta:
¿Esto pasa porque el autor usa otra distro para codear no?

Respuesta:
El primero de los arreglos, la verdad, no sé cómo es que al autor le anda. Me imagino que debe tener la variable QTDIR en su entorno.

Los otros arreglos es porque al autor no se le ocurrió que alguien pudiera querer instalar la documentación en otro lugar que no sea ahí donde él la puso.

En la mayoría de los programas, uno le pasa una variable “–docdir” o similar, para indicar donde van los docs, pero este no la recibe.

Pregunta:
¿El primero de los arreglos no es el tipo de cosas que uno querría mandar upstream?

Respuesta:
Sí, el segundo no, porque es muy quick&dirty, pero habría que hacer un arreglo para que el makefile reciba el docdir por parámetro.

Pregunta:
¿Estos errores los arregla el developer o se siguen “parcheando”?

Respuesta:
La idea es mandarlos a Upstream, para no tener que parchearlos cada vez.

Compilación

Ya estamos listos para hacer la prueba de la primera compilación. Para generar un paquete .deb, sencillo, sin generar el paquete fuente, desde el directorio “valkyrie-1.2.0″ y escribimos: “fakeroot debian/rules binary”.

fakeroot es un comando que sirve para “simular” que el paquete está armado como root, ya que los archivos tienen que grabarse con el uid de root y demás. Pero no está siendo realmente root. debian/rules es el archivo que editamos hace un ratito. binary es la regla de para armar el paquete binario (es decir el .deb).

Ejecuten el comando que puse y vean la salida… Si todo sale bien, va a compilar, y luego va a “instalar” (pero en un directorio interno del paquete) y luego va a generar el .deb. Esto (dependiendo de la compu) va a llevar un rato. Así que pueden aprovechar para hacer una pausa mientras compila, o preguntar lo que no les haya quedado claro hasta ahora.

Pregunta:
dpkg-gencontrol: warning: unknown substitution variable ${miscepends} ?
/usr/bin/fakeroot: 152: debian/rules: not found

Respuesta:
Si, es un warning común. No tiene importancia, lo que te está diciendo es que esa variable mágica no la va a usar. Pero no pasa nada.

Importante Memo y sugerencias:

• Cada línea de la descripción larga debe comenzar con un espacio.
• En caso de error es posible correr nuevamente el comando, pero también podemos hacer un fakeroot debian/rules clean
• Verificar la disponibilidad del paquete libc6-dev,
• sudo aptitude install libstdc++6-dev
• Descomprimir el paquete como user (no root/sudo)
• Para compilar de vuelta, conviene: fakeroot debian/rules clean y luego fakeroot debian/rules binary aunque no es obligatorio.
• TODAS las líneas tienen que empezar con espacio. (TODAS == todas las de la descripción larga) (repetitivo uh? xD)

En http://www.marga.com.ar/~marga/debian/packages/valkyrie-1.2.0/ está mi paquete

Pueden verificar las líneas faltantes, a modo de corrección en: http://www.marga.com.ar/~marga/debian/packages/valkyrie-1.2.0/debian/changelog

Bueno… Por si hay alguno que todavía no pudo… Ahora se genero el paquete .deb, pueden instalarlo y ejecutar el programa “valkyrie”. Para poder usarlo van a necesitar correr valgrind sobre algún programa binario. Por ejemplo el “ls”. Apreten el botón de “Run valgrind”, escriban “ls” (o lo que quieran) en la caja de “Binary”, “Ok” y luego “Run valgrind” otra vez.

Otros archivos

Nos quedan por editar un par de archivos más. Ninguno muy importante
*) debian/menu es un archivo para los menúes de Debian. Es bastante fácil de editar. Si lo abren, donde dice “needs” tiene que quedar “X11″ y donde dice “section” tiene que quedar “Applications/Programming”. Si quieren saber en qué sección va un paquete, hay que buscarlas en /usr/share/doc/menu/menu.txt.gz

El archivo menu lleva al final de las líneas, porque va todo en una sola línea. ( es lo mismo que que no haya fin de línea).

*) debian/watch es un archivo que sirve para verificar si hay nuevas versiones de un paquete. El que viene ya trae varios ejemplos que pueden servir. En nuestro caso nos quedamos con el primer ejemplo, y reemplazamos de la siguiente manera: “http://www.valgrind.org/downloads/ valkyrie-(.*).tar.bz2″. Todos los comentarios se pueden borrar.

*) debian/manpages es un archivo que indica qué manpages se deben instalar. En este caso nuestras manpages son ficticias, porque son las del ejemplo, sin editar, pero de todas maneras las incluimos en este archivo, de a una por línea: “debian/valkyrie.1″ y “debian/vk_mergelog.1″.

Este archivo manpages nos permite indicar donde está la man page. Nosotros le ponemos el nombre y la regla “dh_installman” del debian/rules se encarga de instalarla donde corresponde.

*) Esto sucede con muchas reglas de debhelper. Por ejemplo, dh_installdocs, instala los archivos que se encuentren en el archivo “docs” dentro de /usr/share/doc/paquete. En “docs” vamos a dejar: AUTHORS NEWS README

Pregunta:
¿Esto que estás diciendo ahora es para hacerlo antes de la configuración y compilación o se puede hacer después?

Respuesta:
Se puede hacer en cualquier momento. Uno en general trata de compilar rápido, para ver que ande, y después le empieza a hacer retoques.

Pregunta:
No tengo un debian/manpages, lo agrego? y Las manpages van una por linea y sin nada alrededor? comillas, etc?

Respuesta:
Si, debemos agregar debian/manpages y sí, sin nada alrededor.

Continuamos,

Una vez que el paquete haga todo bien, ya se puede generar el paquete fuente, que es el que van a necesitar para poder subirlo a Debian o Ubuntu. Ese paquete se genera haciendo “dpkg-buildpackage -rfakeroot”.

Cuando ejecutan ese comando, no sólo se compila el binario como hacíamos hasta ahora, sino que también se genera el paquete fuente.

El paquete fuente consiste de tres archivos. Uno es el .orig.tar.gz que nosotros generamos al principio. Otro es un archivo de texto con extensión .dsc, que incluye la descripción del paquete generado y el otro es un archivo .diff.gz que incluye todos los cambios que ustedes hayan realizado al paquete.

Esos tres archivos son los que van a subir a Ubuntu. En el caso de Debian, se suben esos tres archivo + el .deb compilado.

Por ejemplo, habría que escribir las páginas man, que por ahora están las del ejemplo.

Pregunta:
Eso lo hacemos después que comprobamos que el .deb salio sin problemas?
Esos tres archivos son los que van a subir a Ubuntu. En el caso de Debian, se suben esos tres archivo + el .deb compilado.

Respuesta:
Si, antes de subirlo el paquete tiene que estar 10 puntos.

Pregunta:
¿En ubuntu no se sube el .deb porque compilan ellos?

Respuesta:
Si. Compilan para todas las arquitecturas. En Debian se compila para todas menos para la que uno subió.

-En Ubuntu solo se compila para x86, a64 y sparc-

Vale decir que Debian compila para MUCHAS arquitecturas (del orden de 12) y Ubuntu solo 3.

Pregunta:
Por ejemplo, si hay un cambio en la funcionalidad del paquete, lo ves en algun lado y actualizas la manpage? eso lo hace el mantainer?

Respuesta:
Si. Si la página man la mantenés vos, vos tenés que fijarte que esté actualizada.

Pero algo muy interesante para hacer es mandarle la página man a “upstream” (o sea a los autores originales) y que sean ellos los que la mantengan de acá en adelante.

Pregunta:
Genere el source… pero me dice que no puede firmarlo, donde pongo mi key?

Respuesta:
Tendrías que generar tu llava con gnupg pero si no, podés generar el paquete con: dpkg-buildpackage -rfakeroot -us -uc, y no te pide firmar.

Comentario de un concurrente:
Una advertencia que me tiró al final dice:

dpkg-gencontrol: advertencia: variable ${miscepends} de sustitución desconocida

Pregunta:
Con que estes en .gnupg es suficiente?

Respuesta:
No, tenés que tener la llave generada.

Bueno, eso es todo. Les dejo un par de links por si quieren leer más
http://www.debian.org/doc/maint-guide/
http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html

Gracias a des por la atención a los usuarios, a maxyz por contestar por privado, a beuno por los aportes de Ubuntu. Y todos ustedes por venir.

Disertante:

Margarita Manterola

Fuentes:

http://charon.damianv.com.ar/tutorial_marga.log http://www.vivalinux.com.ar/eventos/tutorial-irc-de-paquetes-deb.html

Un gran abrazo a todos.

::: LikeVinyl 2007 :::