La acumulación de Debian cadena de herramientas es un conjunto de utilidades de software utilizado para crear Debian paquetes fuente ( .dsc
) y los paquetes binarios de Debian ( .deb
archivos) desde aguas arriba de origen bolas de alquitrán .
Estas herramientas se utilizan en el proyecto Debian y también en distribuciones basadas en Debian como Ubuntu .
Descripción general
El código fuente del software libre se distribuye normalmente en archivos tar comprimidos llamados tarballs. Debian es una distribución orientada a binarios, lo que significa que sus deb
paquetes incluyen binarios precompilados y archivos de datos organizados en una jerarquía de sistema de archivos que espera el software. Por lo tanto, la cadena de herramientas de construcción de Debian necesita instrucciones sobre cómo usar el sistema de construcción ascendente para construir deb
paquetes correctos .
Estas instrucciones se almacenan en el debian
subdirectorio, que se agrega al árbol de fuentes del software que está empaquetando el mantenedor del paquete . Si bien es posible construir el paquete directamente desde el árbol de fuentes modificado, es una práctica estándar crear paquetes de fuentes , que contienen los cambios que el mantenedor hizo a las fuentes ascendentes en forma redistribuible.
Paquetes fuente
Un paquete fuente típico de Debian consta de tres archivos:
- El tarball original (
orig.tar
): una mera copia del tarball original si está entar
formato y no es necesario realizar cambios, o un tarball reempaquetado. Esto último puede suceder si contiene una instantánea de un sistema de control de versiones que nunca se publicó en formato tarball, o si el responsable de mantenimiento necesita eliminar archivos que no son compatibles con las Pautas de software libre de Debian . - El
debian.tar
archivo, que contiene cambios en la fuente de origen realizados por el mantenedor del paquete. Esto incluye eldebian
directorio completo . Cualquier archivo modificado fuera de él se agrega a archivos de parche dentro deldebian/patches
directorio, que se aplican automáticamente antes de compilar. - El
dsc
archivo, que es un archivo de texto con metadatos , como los nombres de todos los archivos que constituyen el paquete fuente y sus sumas de comprobación SHA256 . También contiene la firma del creador del paquete fuente.
Por ejemplo, un paquete fuente denominado foo
con la versión 1.2.3 ascendente y la revisión 4 de Debian puede constar de los siguientes archivos:
foo_1.2.3.orig.tar.gz
foo_1.2.3-4.debian.tar.gz
foo_1.2.3-4.dsc
Se crea un paquete fuente utilizando la dpkg-buildpackage
herramienta o su contenedor debuild
. Cuando se invoca para crear un paquete fuente, dpkg-buildpackage
llama a las reglas del mantenedor para limpiar el árbol fuente de cualquier archivo intermedio, realiza varias comprobaciones de cordura y, finalmente, firma el dsc
archivo con la clave del empaquetador utilizando la debsign
utilidad.
El proceso inverso - producir el árbol de código fuente descomprimido a partir de un paquete de código fuente - se logra usando la dpkg-source
utilidad, que extrae el tarball original a un subdirectorio, extrae el debian.tar
tarball dentro de él y aplica cualquier parche de quilt presente. Este es el primer paso que realiza un sistema de compilación al compilar paquetes binarios a partir de un paquete fuente.
Los paquetes fuente más antiguos (que utilizan el formato fuente 1) tienen un .diff.gz
archivo en lugar del debian.tar
. Esta es una diferencia unificada que contiene el debian
directorio y cualquier cambio en la fuente ascendente que no sea administrado por un sistema de parches.
El directorio de Debian
El directorio debian contiene archivos utilizados por dpkg-buildpackage
para crear paquetes binarios y fuente. A diferencia de RPM , que usa un solo spec
archivo para las instrucciones, las herramientas de Debian usan un subdirectorio completo con varios archivos. Tres archivos son necesarios como mínimo para construir correctamente un paquete - changelog
, control
y rules
. Un cuarto archivo, copyright
es obligatorio por la política de Debian, pero es un requisito legal más que técnico.
Por diseño, todos los archivos del debian
directorio son archivos de texto, la mayoría de los cuales son legibles por humanos y se editan con un editor de texto simple.
debian / changelog
Este archivo contiene información sobre todas las versiones del paquete desde que se creó. Las herramientas de compilación solo procesan la entrada superior, que se utiliza para determinar la versión del paquete, la urgencia (que solo es relevante para Debian) y los errores en la distribución que corrige esta versión.
Por ejemplo, para un paquete con nombre foo
, una debian/changelog
entrada de ejemplo puede leerse así:
foo (1.2.3-1) inestable; urgencia = baja * Nueva versión upstream. * Se eliminó 02_manpage_hyphens.dpatch, se corrigió en sentido ascendente. * Agregado 04_edit_button_crash.dpatch: corrige un bloqueo después de presionar el botón de edición. (Cierra: # 654321) * debian / control: foo debería entrar en conflicto con libbar. (Cierra: # 987654) - John DoeVie, 30 de noviembre de 2007 15:29:42 +0100 @example.com>
Debian proporciona dos utilidades principales para manipular el debian/changelog
archivo:
dch
se utiliza para agregar nuevas entradas al registro de cambios o modificar las existentes.dpkg-parsechangelog
analiza la entrada más reciente y extrae datos de ella en unKey: value
formato similar adebian/control
. Se utiliza principalmente en scripts.
debian / control
Este archivo contiene información sobre el paquete fuente y todos los paquetes binarios que crea (puede haber más de uno; por ejemplo, el paquete fuente libbar
puede servir como fuente para paquetes binarios libbar0
, que contiene solo la biblioteca compartida y libbar-dev
, que contiene un archivo estático versión de la biblioteca y archivos de encabezado).
Enumera (entre otros) elementos tales como el nombre del paquete, el responsable del mantenimiento, las arquitecturas de destino (para paquetes binarios), las dependencias de compilación (paquetes que deben instalarse para que el paquete se compile correctamente) y las dependencias (paquetes que deben instalarse para que el paquete funcione). funcionan correctamente cuando están instalados).
debian / reglas
Este archivo es un script que se invoca dpkg-buildpackage
con un solo argumento que especifica la acción a realizar ( clean
, build
, install
, binary
). Aunque técnicamente puede ser cualquier tipo de script, siempre se implementa como un archivo MAKE .
Además de invocar el sistema de compilación ascendente, la mayoría de las instrucciones debian/rules
son muy repetitivas y ubicuas y, por lo tanto, prácticamente todos los debian/rules
archivos envuelven esta funcionalidad en los scripts debhelper . Por ejemplo, determinar automáticamente las dependencias en función de las bibliotecas compartidas utilizadas es una acción muy común y, por lo tanto, en lugar de incluir el código necesario para hacerlo, el debian/rules
archivo simplemente llama dh_shlibdeps
. Otros ejemplos de scripts de debhelper incluyen dh_installdocs
, que instala archivos de documentación de stock, como debian/copyright
en sus ubicaciones apropiadas, o dh_fixperms
, que asegura que los archivos en el paquete tengan los derechos de acceso correctos (por ejemplo, los ejecutables /usr/bin
tienen el bit "ejecutable" establecido, pero solo se pueden escribir por el superusuario).
Dado que las secuencias de debhelper
scripts son repetitivas en sí mismas, algunos paquetes simplifican los debian/rules
archivos directamente usando dh o CDBS en lugar de ejecutar cada debhelper
comando directamente.
Sistemas de parches
A veces, un mantenedor necesita modificar la fuente original. Si bien, en el pasado, esto se hacía a menudo simplemente editando los archivos en su lugar e incluyendo los cambios en el diff.gz
, esto podría dificultar el mantenimiento cuando se lanzaban nuevas versiones, porque todos los cambios tenían que ser examinados y fusionados cuando era necesario.
El formato de origen más nuevo, 3.0 (quilt), utiliza el sistema de parches de quilt , para permitir que las modificaciones se dividan en grupos de parches separados lógicamente, cada uno de los cuales se ocupa de un cambio y se puede enviar en sentido ascendente tal cual. Estos parches viven en debian/patches
.
También hay paquetes que utilizan otros sistemas de parches, como dpatch
. Genera y ejecuta scripts de shell que son archivos diff unificados no estándar con un encabezado, que sin embargo son compatibles con la diff
utilidad estándar . El debian/rules
archivo se modifica para llamar dpatch apply-all
antes de compilar el paquete binario y dpatch deapply-all
antes de compilar el paquete fuente (y limpiar los subproductos de compilación). quilt
y algunos otros sistemas de parches eliminan la necesidad de encabezados especiales y utilizan archivos de diferencias estándar.
Seguimiento de cambios en paquetes fuente: debdiff e interdiff
A veces, un usuario puede querer ver las diferencias entre dos paquetes fuente, por ejemplo, para generar un parche propuesto contra la versión que se encuentra actualmente en el repositorio para incluirlo en el sistema de seguimiento de errores de la distribución . Si ambos paquetes usan la misma versión anterior, esto se puede hacer usando la debdiff
herramienta, lo que produce diferencias entre dos árboles de origen con cambios de empaque incluidos.
Si los archivos tar upstream para las dos versiones son diferentes, no se puede utilizar una comparación tan ingenua. En su lugar, la interdiff
utilidad se puede utilizar para producir una diferencia entre dos archivos de diferencias (en este caso, entre dos diff.gz
archivos). Un inconveniente es que una interdiff
salida requiere más esfuerzo para aplicar, y el que aplica los cambios también debe encontrar y descargar el tarball ascendente más nuevo, lo que generalmente se hace usando la get-orig-source
regla en debian/rules
. [1]
Controles de cordura con lintian
Esta herramienta proporciona comprobaciones automatizadas de errores de empaquetado comunes tanto en paquetes binarios como de origen, incluidas violaciones de la política de Debian y posibles problemas de compatibilidad.
Mientras que un mantenedor generalmente tiene como objetivo corregir todos los problemas señalados por lintian
, diferentes distribuciones pueden tener diferentes políticas con respecto a ellos. Por ejemplo, Ubuntu requiere que todos los paquetes que se originan en Ubuntu estén limpios, pero para un paquete combinado en Ubuntu desde Debian, no existe tal requisito: los nuevos cambios simplemente no deberían introducir advertencias además de las existentes. Esto se hace para minimizar la divergencia entre los paquetes Debian y Ubuntu.
A continuación, se muestran ejemplos de lintian
salidas:
W: foo fuente: source-contains-CVS-dir config / CVSNORTE:N: el paquete contiene un directorio CVS. Probablemente fue incluido porN: accidente, ya que los datos CVS transitorios generalmente no pertenecen a los paquetes.N: Exportar desde CVS en lugar de utilizar una caja.NORTE:
W: libfoo-dev: debian-changelog-line-too-long line 2NORTE:N: La línea dada de la última entrada del registro de cambios tiene más de 80 columnas. SemejanteN: las entradas del registro de cambios pueden verse deficientes en las ventanas de la terminal y en los mensajes de correoN: y ser molesto de leer. Envuelva las entradas del registro de cambios en 80 columnasN: o menos cuando sea posible.NORTE:
I: foo: arch-dep-package-has-big-usr-share 3399kB 77%NORTE:N: el paquete tiene una cantidad significativa de datos independientes de la arquitecturaN: en / usr / share, mientras que es un paquete dependiente de la arquitectura. Esto esN: desperdicio de espacio espejo y ancho de banda, ya que luego terminamos conN: múltiples copias de estos datos, una para cada arquitectura.NORTE: N: Si los datos en / usr / share no son independientes de la arquitectura, es unN: violación de la política, y en este caso, debe mover esos datosN: en otros lugares.NORTE: N: Ver también:N: http://www.debian.org/doc/developers-reference/ch-best-pkging-practiceN: s # s-bpp-archindepdata
Entornos de construcción aislados
Los paquetes fuente están pensados para ser compilables en cualquier instalación de la versión de distribución de destino, siempre que se cumplan las dependencias de compilación. Además, las compilaciones pueden verse afectadas por paquetes que ya están presentes en el sistema.
Para verificar que un paquete se basa en cualquier sistema y para excluir cualquier factor externo, se utilizan herramientas para crear entornos de construcción aislados. Estos son pbuilder
(Personal Builder) y sbuild
.
Estas herramientas mantienen sistemas de trabajo mínimos en chroot , instalan solo las dependencias de compilación necesarias enumeradas en debian/control
y las eliminan cuando finaliza la compilación. Por lo tanto, pbuilder
un mantenedor de paquetes puede detectar si algunas dependencias de compilación no se especificaron en debian/control
. Además, pbuilder
permite realizar pruebas de compilación para distribuciones distintas de la que está ejecutando el mantenedor: por ejemplo, para la versión de desarrollo, mientras se ejecuta la versión estable.
sbuild
está diseñado para la integración con demonios de compilación automatizados ( buildd
). Lo utilizan los servidores de compilación de Debian, que compilan automáticamente paquetes binarios para cada arquitectura compatible. El servicio Launchpad proporciona demonios de compilación similares para Ubuntu, tanto la distribución oficial como los archivos de paquetes personales (PPA).
Ver también
Referencias
- ^ "Capítulo 4 - Paquetes fuente" . Manual de políticas de Debian . Consultado el 1 de octubre de 2014 .