Creative Commons License
Excepto donde se indique otra cosa, todo el contenido de este lugar está bajo una licencia de Creative Commons.
Taquiones > debian > Anotaciones sobre el uso de dpkg-buildpackage

Anotaciones sobre el uso de dpkg-buildpackage

Missing orig tarball y debpool

Si el programa debpool falla y en el registro aparece esta referencia es debido a que nuestro paquete no tiene el archivo orig y por tanto no puede insertarlo en el repositorio.

¿ A qué se debe esto si hemos seguido la vía habitual ? Es decir, hemos construído el paquete con

$ dpkg-buildpackage -rfakeroot -uc -us

pero no nos hemos dado cuenta de que en el informe final aparece una línea como la siguiente:

...
dpkg-genchanges: not including original source code in upload
...
$

Y esto es debido, según la documentación de dpkg-genchanges a que hemos realizado varios cambios en el número de versión Debian (el que aparece tras el guión) y si éste no termina en 0 ó en 1, este programa no envía dicho archivo 'orig'. Para forzarle a ello se debe utilizar otro parámetro:

$ dpkg-buildpackage -rfakeroot -uc -us -sa
...
dpkg-genchanges: including full source code in upload

y entonces sí que se envía correctamente mediante debrelease.

Obtener dependencias de un paquete

Llegado el caso de tener que reconstruir un paquete Debian una de las cosas más ... complicadas por decir algo, es obtener también los paquetes necesarios para dicha operación.

Gracias a Steve Kemp y a su artículo por fín encuentro el modo fácil de hacerlo.

Sí, seguramente podría haberlo encontrado mucho antes, pero el mundillo Debian es cada vez más amplio y yo cada vez tengo menos tiempo.

En resumen queda así:

  1. Añadimos el origen de los fuentes al archivo /etc/apt/sources.list si no está ya allí.
  2. Elegimos un directorio y nos cambiamos a él, dado que tanto el paquete fuente como los paquetes binarios se van a construír en él.
  3. Descargamos los fuentes del paquete

    $ apt-get source foo
    
  4. Descargamos e instalamos los paquetes de los que depende:

    $ sudo apt-get build-dep foo
    
  5. Efectuamos los cambios en el paquete

    $ cd foo-1.0
    $ patch -p0 < ...
    

    ó manualmente si no disponemos de un parche.

  6. Anotamos el cambio en el registro del paquete utilizando un parámetro especial que indica que dicho cambio no ha sido realizado por el mantenedor principal.

    $ debchange --nmu
    

    de tal manera que se añade un registro a debian/changelog de esta forma

    nfs-user-server (2.2beta47-23.1) unstable; urgency=low
    
    
    * Non-maintainer upload.
    * 
    
    
    -- Victor Moral <victor@venexma.net>  Thu, 25 Oct 2007 09:15:13 +0200
    

    Puede verse que se ha aumentado la versión de paquete Debian añadiéndole una subversión .1, y que se ha añadido un texto literal a la bitácora.

  7. Reconstruímos el paquete usando algunos parámetros especiales dado que no somos los mantenedores oficiales de los mismos:

    $ debuild -uc -us -sa
    

    Los parámetros empleados inhiben la firma digital del paquete y se aseguran se añadir el fuente original, por si es necesario enviarlo a un repositorio local.

  8. Ahora podemos instalar el paquete en nuestro sistema con alguna de estas dos opciones:

    $ sudo debi 
    
    
    $ sudo dpkg -i ../foo-1.0-1.1_i386.deb
    
  9. O enviarlo a un repositorio local para instalarlo en varias máquinas más.

Retener un paquete

En el artículo de referencia de la sección anterior, un usuario cuenta su historia personal con la modificación de paquetes Debian.

Todos sus clientes emplean Gnome como escritorio y se quejaban de que les aparecía el menú de aplicaciones Debian junto al otro, por lo que estaban bastante confusos. El administrador decide parchear el paquete gnome-panel para eliminar dicha entrada, y procede más o menos como se ha explicado antes.

El problema aparece cuando al día siguiente de haber construído e instalado el programa, una actualización de seguridad marca el mismo paquete para ser reinstalado, con lo que perdería el trabajo y debería empezar de nuevo.

Este administrador tenía varias opciones en ese momento.

  1. Marcar el paquete como retenido (hold).
  2. Reconstruir el paquete con una versión mayor para que esté siempre por delante del paquete oficial.
  3. Ajustas las preferencias de repositorios (pinning).

Para retener el paquete existen varios métodos:

# echo package_name hold | dpkg --set-selections

# wajig hold package_name

# aptitute hold package_name

y para liberarlo y que se pueda incluir en la lista de paquetes actualizables tenemos lo contrario:

# echo package_name install | dpkg --set-selections

# wajig unhold package_name

# aptitude unhold package_name

Para añadir un número de versión mayor al paquete que hemos modificado podemos utilizar el parámetro --newversion del programa dch.

Prioridades de repositorios

Respecto a la posibilidad de marcar el paquete como preferente es necesario retocar la configuración de apt, modificando el archivo /etc/apt/preferences, entre otros, siendo un proceso sencillo pero que necesita de un estudio mínimo por las consecuencias que puede acarrear.

Sólo dejo aquí constancia de los niveles de prioridad, puesto que existen otras fuentes, como el artículo de CRySoL, el de Linuxtopia y la sección 3.5 del documento APT HOWTO.

Los niveles de prioridad pueden ser:

  • < 0: el paquete no se instalará nunca.
  • 0 a 99: se seleccionará paquetes con estas prioridades sólo si no está instalado y no existe otra versión disponible.
  • 100: ésta es la prioridad de los paquetes que están instalados recientemente.
  • 500: y ésta es la prioridad predeterminada de todos los paquetes si no se le indica otra cosa.
  • 990: es el valor que recibe un paquete instalado mediante la imposición de una distribución concreta (parámetro --target-release de apt-get).
  • > 1000: son aquellos paquetes en los que se permite la vuelta atrás, es decir, a instalar un versión anterior del mismo.

Enlaces