Translation(s): English - Español - Português Brasileiro

(!) ?Discussion



Tutorial de construcción de un paquete

Este tutorial está basado en el Debian Women Build it Event levado a cabo por Margarita Manterola (en colaboración con el OpenHatch project) el 07-Mayo-2011

Este tutorial pretende enseñar como descargar un paquete, recompilarlo, aplicarle cambios y preparar estos cambios para poder enviarlos al bug como un parche.

Requisitos

Se necesitan muy pocos conocimientos previos para seguir este tutorial, simplemente no tienes que tener miedo de la linea de comandos :-)

Requisitos técnicos:

Recuerda:

   sudo apt-get install build-essential fakeroot devscripts

Primer paso: usando deb-src

Una vez que hayas instalado los paquetes necesarios, lo siguiente que tienes que hacer es asegurarte que tienes algunos "repositorios de código fuente" configurados en tu ordenador. Abre tu fichero /etc/apt/sources.list y comprueba que tienes una o más lineas que empiecen con deb-src. Estas lineas se necesitan para trabajar con los paquetes de código fuente.

Si no tienes ninguna linea deb-src, necesitarás añadir al menos una. Por lo general, esto se consigue copiando una de las lineas deb cambiándola a deb-src. Puedes hacerlo ejecutando un editor con permisos de administración (sudo gedit, sudo kate o sudo vim) y añadiendo esta linea:

deb-src http://http.us.debian.org/debian unstable main

Normalmente, es buena idea usar unstable como repositorio, ya que así estarás trabajando con la última versión del paquete, pero si tu intención es modificar un paquete tal y como esta en stable o en testing también puedes usar estas distribuciones. Si usas stable/testing/lo-que-sea como distribución, obtener el código fuente de unstable no te afectará.

Una vez hayas añadido la linea, necesitarás hacer:

   sudo apt-get update

para actualizar la lista de paquetes disponibles para instalar.

Eligiendo el paquete

Con las URL de código fuente añadidas a tus repositorios apt, ya podrás obtener el código fuente de cualquier paquete Debian que quieras. En este tutorial, bajaremos el código fuente de un paquete como ejemplo y le haremos una pequeña modificación para que funcione mejor.

Siempre es buena idea que tengas un directorio separado del resto para trabajar con código fuente. En el caso de que no dispongas de uno, te sugiero que crees el directorio src con otro llamado debian dentro:

mkdir -p src/debian/; cd src/debian

Dentro de este directorio pondremos el código fuente del paquete con el que queremos trabajar. En este ejemplo, usaremos un paquete llamado fdupes, una herramienta para detectar ficheros duplicados, y arreglaremos el bug de Debian 585426.

Tendrías que instalar el paquete (o comprobar si ya lo tienes instalada en su última versión) antes de seguir, ya que necesitarás tener sus dependencias cuando quieras instalar el paquete modificado.

Si no tienes el paquete fdupes instalado, lo puedes instalar haciendo

   sudo apt-get install fdupes

y comprobar que el bug aún está ahí. Puedes comprobarlo ejecutando

   fdupes --help

y viendo que la segunda linea de información para la opción --debug aún no tiene sentido.

Descargando las dependencias necesarias para crear el paquete

Para construir casi cualquier programa, necesitarás algunas dependencias instaladas. Las dependencias son los programas o librerías que se necesitan para compilar tu programa. Normalmente son un montón de paquetes acabados en -dev, pero también pueden ser otras cosas com automake o gcc, dependerá de la cantidad de herramientas de desarrollo que ya hayas instalado en la máquina.

apt te proporciona una manera muy fácil para instalar las dependencias que necesitas:

   sudo apt-get build-dep fdupes

Una vez que te hayas descargado estas herramientas, estarás preparado para construir el paquete.

Reconstruyendo sin hacer cambios

Antes de hacer ningún cambio en el código, vamos a construir el paquete tal y como está ahora, para asegurarnos de que se construye y se instala de manera adecuada. Haz:

   fakeroot debian/rules binary

Este es el comando, parecido a make, que construye el paquete. Probablemente este comando tardará un rato en ejecutarse, ya que normalmente primero tiene que ejecutar './configure', después compilar el código fuente y finalmente construir los paquetes. De hecho, ejecutará los comandos listados en el fichero debian/rules y, con suerte, acabará con un mensaje parecido a:

   dpkg-deb: building package `fdupes' in `../fdupes_1.50-PR2-3_<tu arquitectura>.deb'

pero en tu idioma. <tu arquitectura> puede ser i386, amd64, dependiendo de la arquitectura que tengas en tu máquina.

Una vez el paquete se haya construido correctamente, el siguiente paso es instalar este fichero con:

   sudo dpkg -i ../fdupes_1.50-PR2-3_<tu arquitectura>.deb

Después de esto, comprueba que el bug aún está presente ejecutando fdupes --help.

Editando el código fuente

Vamos ya a arreglar el bug. Ahora viene la parte divertida. Cuando se intenta arreglar el bug de un paquete, puede ser que el bug esté en el código fuente original o puede ser que esté relacionado en cómo este programa fue empaquetado para Debian. Dependiendo de dónde esté el problema, se editarán diferentes ficheros.

En este caso particular, el paquete usa la herramienta dpatch, una herramienta que sirve para gestionar los parches de un paquete. Por lo tanto, tendremos que usar esta herramienta. Otros paquetes usan una herramienta diferente para gestionar los parches, llamada quilt, pero no la vamos a cubrir en este tutorial.

Para crear un parche nuevo, necesitarás hacer lo siguiente:

   dpatch-edit-patch 80_bts585426_fix_help 70_bts537138_disambiguate_recurse.dpatch

Esta orden iniciará una nueva consola dentro de un entorno especial, donde podrás editar tus ficheros. Después dpatch se encargará de obtener las diferencias con los ficheros originales. El primer parámetro es el nombre asignado al parche nuevo, el segundo es el último parche que se tiene que haber aplicado antes del nuevo. El nombre del parche se ha escogido para que coincida con el patrón establecido por el mantenedor del paquete.

Ahora tenemos que editar el fichero fdupes.c. Puedes editar el fichero con tu editor favorito (vi fdupes.c, gedit fdupes.c, kate fdupes.c, etc). Ves a la linea 1066 y bórrala. La linea dice:

printf("                  \teach set of duplicates without prompting the user\n");

Una vez hayas acabado, teclea exit en la consola. De esta manera, saldrás del entorno especial que dpatch había creado y tendrás un parche nuevo en el directorio debian/patches/. Comprobémoslo con:

   cat debian/patches/80_bts585426_fix_help.dpatch

Para que este parche se aplique, necesitas editar el fichero debian/patches/00list y añadir

   80_bts585426_fix_help

como última linea.

El fichero 00list es el fichero de dpatch que lista todos los parches que se aplicarán. Se aplicarán en orden, des del primero que aparece en la primera linea hasta el que aparece en la última.

Antes de reconstruir el paquete con este parche, queremos hacer nuestro paquete diferente del original y así después poder extraer los cambios y poder enviar el parche al bug. Para poder hacerlo, teclea:

   dch -n

Esto añadirá ua nueva entrada en el fichero changelog, quizás con tu nombre (dependiendo de algunas configuraciones que ahora no vamos a cubrir), con la fecha actual y abrirá el changelog con el editor de linea de comandos configurado. En el caso que sea vi, y sea la primera vez que usas vi, puedes empezar a editar apretando la tecla Insert y una vez hayas acabado, puedes guardar y cerrar tecleando ESC :wq.

Así que ahora estás editando el fichero changelog. Lo que se tiene que introducir en este fichero es alguna descripción del cambio que hemos hecho. Por ejemplo:

   Added a patch to fix the --help issue with the --debug option. Closes: #585426".  

Haz esto en la linea que tiene un * vacío.

Construyendo el paquete modificado

Una vez hecho esto, primero tenemos que limpiar el directorio de construcción, para que quede todo como estaba al principio, con:

   fakeroot debian/rules clean

Y después ya podemos reconstruir el paquete otra vez con el mismo comando de antes:

   fakeroot debian/rules binary

En el caso de que necesites depurar el paquete compilado, en particular si se trata de arreglar una Segmentation Fault (violación de segmento), probablemente querrás compilarlo de la siguiente manera para que el código no esté ni optimizado ni stripped y así sea más fácil de depurar:

   DEB_BUILD_OPTIONS=nostrip,noopt fakeroot debian/rules binary

Verás diversas salidas de compilación por pantalla. Habitualmente esto no es muy interesante, a menos que esté buscando un bug relacionado con la compilación del paquete. Normalmente, dejo que esto se haga minetras hago alguna otra cosa (tomar algunas galletas para el café, por ejemplo).

Esta vez, el paquete creado tendría que ser ../fdupes_1.50-PR2-3.1_<your arch>.deb, la versión ha cambiado debido a que dch lo cambió por nosotros en el changelog (-3.1 en lugar de -3).

Instalando y probando el paquete modificado

Instálalo con:

   sudo dpkg -i ../fdupes_1.50-PR2-3.1_<your arch>.deb

y prueba que la ayuda (--help) es ahora la correcta. :-)

Si lo que has hecho ha emperoado las cosas, siempre puedes volver a la versión de Debian haciendo:

  apt-get install --reinstall fdupes=<versión_anterior>

Construyendo el paquete de código fuente

Una vez el bug está arreglado, también querrás construir el paquete de código fuente. Esto quiere decir obtener no sólo el fichero .deb sino también los otros ficheros que nos bajamos al principio. Esto se hace con:

   dpkg-buildpackage -us -uc

Los parámetros extra son para evitar que firmemos el paquete ya que ahora mismo no necesitamos hacerlo.

Si ya has construido el paquete de código fuente, ves al directorio anterior con cd .. y comprubea qué ficheros hay con ls. Verás que ahora hay más ficheros, incluyendo 2 ficheros dsc, uno para el paquete original y otro para el paquete que acabas de hacer.

Enviando tus cambios al BTS

Una vez ya has construido el paquete de código fuente, puedes averiguar las diferencias entre tu paquete y el original usando debdiff:

   debdiff fdupes_1.50-PR2-3.dsc fdupes_1.50-PR2-3.1.dsc > my_first_debdiff.diff

En este caso particular, cómo que hemos usado la herramienta dpatch, lo que tenemos que enviar al BTS como parche es el fichero dpatch que hemos creado, ya que el cambio que hemos hecho está allí dentro.

Pero si no hubiéramos usado dpatch, podríamos usar la salida producida por debdiff y enviarla al BTS.

Eso es todo, ya puedes continuar con el siguiente paquete

Terminaste con la modificación de un paquete. ¡Ahora puedes continuar reparando bugs en otros paquetes Debian! Estos son los comandos importantes que debes recordar:

   apt-get source the-package
   apt-get build-dep the-package
   (...)
   fakeroot debian/rules binary
   dpkg -i the-package-blabla.deb
   dpkg-buildpackage -us -uc
   debdiff package-blabla.dsc package-blabla.1.dsc > another_debdiff.diff

Opiniones

Espero que hayas disfrutado de este tutorial, por favor envíame tus comentarios si lo deseas, o modifica este wiki si quieres agregar información útil que pueda haber dejado fuera.

Preguntas y respuestas

PREGUNTA: ¿El número 80_ en el nombre del parche es estético?

RESPUESTA: Se pone para que los puedas ver ordenados cuando los listes con un ls. El orden de aplicación es el que aparece en en el fichero 00list. Algunos mantenedores escogen poner números, otros no. Pero cuando estés parcheando un paquete deberías intentar seguir los patrones que el mantenedor ha escogido.

PREGUNTA: Respeto a los parámetros de dpatch-edit-patch, ¿de dónde has obtenido los parámetros? Quiero decir el bts****

RESPUESTA: El primero es el nombre de la ruta del parche. He escogido un nombre parecido a los otros. "BTS" son las siglas de "Bug Tracking System", el número es el número de bug que estamos cerrando.

PREGUNTA: ¿Por qué dch escoge el número 3.1?

RESPUESTA: Hemos usado dch -n porque no somos los mantenedores del paquete (n viene de no-mantenedor). Por lo tanto el número es 3.1. Si fuera el mantenedor, habrías hecho dch -i y el número habría sido -4.

PREGUNTA: Cuando envías un parche al BTS, ¿envíamos alguna cosa sobre el changelog?

RESPUESTA: No necesariamente, pero podemos hacerlo, depende del bug que estemos arreglando. Enviar la salida de debdiff siempre es aceptable.

Si estás enviando un parche pequeño y simple es habitual que dejes que el mantenedor escriba el changelog; si es un actualización NMU mayor tendrías que enviar el changelog como parte de tu parche al BTS.

PREGUNTA: ¿Se considera de mala educación enviar un changelog con un NMU?

RESPUESTA: Lo que no gusta a algunos (no todos) mantenedores es que alguien suba un NMU. Enviar un patch al BTS ¡always/immer/siempre/sempre es bien recibido!

PREGUNTA: ¿Cuál es la manera más rápida y fácil para averiguar que herramienta (si la hay) se usa para gestionar los parches?

RESPUESTA: Mirando si hay alguna dependencia de construcción de quilt o de dpatch en el fichero debian/control. O también si hay el fichero debian/README.source.

PREGUNTA: ¿Funciona este flujo de trabajo para todos los paquetes?

RESPUESTA: Este flujo de trabajo es bastante general. La única cosa que puede cambiar es el sistema de gestión de los parches (dpatch/quilt/ninguno). El resto es básicamente siempre lo mismo.

Mira también