¿Por qué usar sbuild sobre pbuilder?

Existen numerosas formas de construir paquetes Debian en un entorno limpio y reproducible. Dos de los más utilizados son pbuilder y sbuild. Personalmente, siempre he usado pbuilder. Encuentro pbuilder mucho más fácil de usar y mantener. No he podido encontrar ninguna comparación lado a lado de los dos. ¿Qué me estoy perdiendo?

¿Qué ventajas hay en usar sbuild sobre pbuilder?

sbuild y pbuilder se han desarrollado a lo largo de los años para tener una funcionalidad casi idéntica, y a medida que se agregan características a ambos, tienden a ser adoptados rápidamente por el otro.

Como el empaquetado de Debian es un formato basado en políticas, es una ayuda importante para determinar si un problema de compilación dado es un error en la implementación del constructor o un problema con el paquete que se está construyendo para tener múltiples implementaciones de un sistema de compilación. Para mantener esto, los sistemas de construcción líderes deben tener partidarios fuertes que los apoyen, en un espíritu de competencia colaborativa para garantizar que tengamos las implementaciones de políticas más correctas disponibles.

La mecánica interna de sbuild y pbuilder difiere considerablemente, por lo que, precisamente, qué paquetes se extraen para satisfacer las dependencias de compilación o cómo se extraen, el mecanismo preciso por el cual se llaman los diversos objetivos en debian / rules, etc. puede diferir, causando algunos ligeros diferencias de comportamiento en casos muy específicos para ciertos paquetes. La mayoría de las veces esto representa un error en una u otra implementación, y a veces refleja una falta de claridad en la política de empaquetado: en cualquier caso, los cambios de comportamiento deben resolverse.

Las compilaciones oficiales tanto en Debian como en Ubuntu usan sbuild (aunque a menudo no es el sbuild disponible en los archivos), lo que algunos desarrolladores consideran una ventaja, ya que tienen una mayor confianza en que su configuración coincide con la que su paquete estará expuesto cuando se construya, aunque si todos hacen esto, perdemos la capacidad de distinguir los errores en la política de los errores en sbuild.

Históricamente, entiendo que el desarrollo de pbuilder se centró inicialmente en las necesidades del desarrollador, ya que el desarrollo de usuario final y sbuild se centró inicialmente en las necesidades de los administradores de archivos y buildd. Recientemente, estos enfoques han cambiado, ya que las personas han construido sistemas de gestión de archivos basados ​​en pbuilder y herramientas de desarrollo más útiles que usan sbuild.

Ambas herramientas (o sus derivados cercanos comúnmente disponibles) admiten el almacenamiento de chroots como tarballs, desempaquetados en el sistema, en volúmenes separados (con ganchos disponibles para montaje especial: por ejemplo, instantáneas LVM), usando sistemas de archivos superpuestos, usando semántica de copia en escritura, etc. Ambas herramientas ofrecen herramientas triviales de línea de comandos para simplificar el caso común (probar-construir un paquete) y una semántica de enlace enriquecida para admitir casos complejos (archivos grandes). Ambos proporcionan un medio para crear un entorno de prueba en un chroot. En resumen, ambas herramientas proporcionan casi cualquier cosa que creas que quieres en una herramienta de creación de paquetes (y ambas tienen flujos ascendentes activos felices de aceptar errores y parches).

En resumen: si está satisfecho con pbuilder, siga usándolo. Si quieres jugar con sbuild, siéntete libre. La mejor herramienta es la que le resulte más cómoda para el tipo de trabajo que realiza.

Siempre es peligroso estar en desacuerdo con Emmet, así que déjame comenzar reconociendo que su respuesta es probablemente más correcta. Sin embargo, personalmente considero que pbuilder es más fácil de usar y más eficiente desde el primer momento.

Si está en Ubuntu 12.10 o posterior, asegúrese de instalar los excelentes scripts de pbuilder, que son un conjunto de envoltorios extremadamente amigables alrededor de pbuilder sin procesar.

Si está en Ubuntu 12.04, puede instalar los scripts de pbuilder desde el repositorio de backports.

Ahora, comparemos y contrastemos la facilidad de uso de las operaciones equivalentes. En estos ejemplos, explicaré cómo usar un chroot ARM alojado en x86, pero los conceptos aún se aplican a un chroot x86 alojado en x86 también. Recuerde, estoy usando los envoltorios de scripts pbuilder.

Una cosa a tener en cuenta es que los scripts pbuilder implementan un poco de convención, similar a cómo Ruby on Rails toma algunas decisiones por usted para que pueda comenzar rápidamente. Trataré de señalarlos a medida que avanzamos.

Crea un chroot

mk-sbuild --arch=armhf quantal

vs

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

veredicto: empate , ambas líneas de comando son bastante simples, y ambas pueden tomar opciones adicionales para casos de uso más sofisticados si es necesario. Sin embargo, tenga en cuenta el nuevo directorio adicional creado por pcreate.

Descargar un paquete fuente

# standard debian/ubuntu method, works in any directory
apt-get source casper

vs.

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

veredicto: leve ventaja para sbuild , porque está utilizando las mejores prácticas estándar de debian / ubuntu. La convención utilizada por pget puede parecer extraña al principio, pero como trabajo en varios paquetes en múltiples versiones de Ubuntu, me gusta la organización que impone. Tenga en cuenta también que apt-get source también extrae la fuente donde sea que ejecute el comando, dejándolo con * .orig.tar.gz, * .debian.tar.gz, * .dsc y el directorio expandido, que personalmente encuentro para se desordenado La belleza de la organización llegará pronto, lo prometo.

Ingrese el chroot, versión efímera

schroot -c quantal-armhf

vs.

ptest quantal-armhf

veredicto: ligera ventaja para pbuild , menos caracteres para escribir son menos caracteres. Tenga en cuenta que en esta versión de ingresar al chroot, cualquier cambio que haga aquí se perderá una vez que salga del chroot. También tenga en cuenta que en schroot, seguirá siendo un usuario normal, mientras que con ptest, estará en el chroot como usuario root.

Ingrese el chroot, guarde la versión de cambios

sudo schroot -c quantal-armhf-source -u root

vs.

ptest quantal-armhf --save

veredicto: ligera ventaja para pbuild , menos caracteres y argumentos de línea de comando más intuitivos, en mi opinión. En esta versión de ingresar al chroot, cualquier cambio que realice allí se guardará para futuras invocaciones.

Construye un paquete dentro del chroot

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

vs.

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

veredicto: pbuild , ahora vemos la primera victoria significativa al usar las convenciones de pbuild. Este es un comando muy simple sin nada más que recordar, en lugar de especificar la arquitectura, el nombre de chroot y requerir una ruta a un archivo * .dsc que requiere sbuild. Además, debe recordar generar un nuevo archivo * .dsc con sbuild, mientras que pbuild lo hará automáticamente por usted.

Construye el mismo paquete en chroot, una segunda vez

En el ejemplo anterior, tanto sbuild como pbuild descargarán e instalarán los build-deps en sus respectivos chroots. Sin embargo, pbuild guarda los archivos .deb descargados en / var, por lo que si invoca pbuild por segunda vez, no tiene que descargar todos los build-deps nuevamente (aunque todavía deben instalarse en el chroot). sbuild no almacena en caché los archivos .deb (al menos no de manera predeterminada) y, por lo tanto, debe descargar todos los build-deps nuevamente además de esperar a que se instalen en el chroot.

veredicto: pbuild por una posibilidad remota . El almacenamiento en caché de los build-deps es una excelente configuración predeterminada, y pbuild es lo suficientemente inteligente como para detectar si hay una versión más nueva de un build-dep en el archivo y desplegará la nueva versión si es necesario. Para un paquete complejo con muchas estructuras de construcción, esta configuración simple le ahorrará minutos de su vida.

Resumen

Fuera de la caja, encuentro que los scripts de pbuilder son mucho más amigables y rápidos que los equivalentes de sbuild. Por supuesto, hay formas de hacer que pbuilder sea aún más rápido (compilar en un tmpfs, deshabilitar algunos de los ganchos chroot), y probablemente también haya los mismos trucos para sbuild, pero no estoy al tanto de ellos.

Espero que esto ayude.