4.1 Conformidad con los estándares

Los paquetes fuente deberían especificar el número de versión más reciente de la política de este documente el cual tu paquete cumplía en su última actualización.

Esta información puede ser usada para archivar automáticamente informes si tu paquete llega a ser demasiado anticuado.

La versión está especificada en el campo de control del Estandar de Versiones. El formato del campo Estandar de Versiones está decrito en Estandar de Versiones, Sección 5.6.10

Regularmente deberías, y especialmente si tu paquete se ha anticuado, comprobar la versión más reciente del Manual sobre la Política y actualizar tu paquete, si fuera necesario. Cuando tu paquete cumple con el nuevo estandar deberías actualizar el campo Estandar de Versiones de tu paquete fuente y lanzarlo. 10

4.2 Dependencias de Paquetes

Los paquetes fuente deben especificar que paquetes binarios requieren ser instalados o no instalados para compilarlo correctamente. Por ejemplo, si para compilar un paquete necesitamos un cierto compilador, entonces el compilador debería ser especificado como una dependencia en tiempo de compilación.

No se necesita especificar explícitamente las dependencias de compilado de un pequeño grupo de paquetes que siempre se necesitan para compilar, linkear o colocar en un paquete de Debian un programa hola mundo estándar escrito en C o C++. Los paquetes requeridos se llaman build-essential, y una lista adicional se encuentra en /usr/share/doc/build-essential/list (la cual se encuentra en el paquete build-essential). 11

Al especificar el sistema de dependencias en tiempo de compilación, uno debe enumerar solamente esos paquetes requeridos explícitamente para la construcción. No es necesario enumerar los paquetes que se requieren simplemente porque algún otro paquete en la lista de las dependencias tiempo de compilación depende de ellos.12

Si se especifican las dependencias en tiempo de compilación, debe ser posible construir el paquete y producir los binaries en un sistema con los solamente paquetes esenciales y de compilado-esenciales instalados y también aquellos requeridos para satisfacer las relaciones en tiempo de compilación (incluyendo cualquier relación implicita). En detalle, esto significa que las cláusulas de la versión se deben utilizar rigurosamente en las relaciones en tiempo de construcción de modo que una no pueda producir paquetes configurados de forma mala o inconsistente cuando las relaciones están satisfechas correctamente.

Declarando relaciones entre los paquetes, Capítulo 7 explica los detalles técnicos.

4.3 Cambios en las fuentes originales

Si se hacen cambios en el código fuente que no son específicos para un sistema Debian, se deben enviar a los autores originales, de la forma que ellos prefieran, para poder ser incluidos en la versión original de paquete.

Si necesitas configurar el paquete de forma distinta para Debian o para Linux, y las fuentes originales no proporcionan un camino para hacer esto, debes añadir dicha configuración (por ejemplo, un nuevo test autoconf o #define) y enviar el patch a los autores originales, con la opción por defecto que ellos tenían. Tu puedes facilmente saltarte la configuración por defecto en tus debian/rules o en cualquier lugar apropiado.

Debes coprobar que la utilidad de configuración detecta la cadena de especificaciones correcta para la arquitectura (relacionado con Las cadenas de especificación de aquitectura, Sección 11.1 para los detalles)

Si necesitas editar un Makefile donde GNU-style configura los scripts que son usados, debes editar los archivos .in mejor que editar directamente el Makefile. Esto permite al usuario reconfigurar el paquete si es necesario. No debes configurar el paquete y editar el Makefile generado! Esto hace imposible a cualquiera, poder reconfigurar más tarde el paquete sin perder los cambios que has hecho.

4.4 La lista de cambios de Debian: debian/changelog

Los cambios en la versión del paquete de Debian se deben explicar brevemente en el archivo de listado de cambios de Debian. 13 Esto incluye las modificaciones hechas en el paquete Debian comparadas con la versión subida, así como otros cambios y actualizaciones hechas al paquete. 14

El formato del debian/changelog permite a las herramientas de construcción del paquete descubrir que versión del paquete va a ser construida y encontrar otra información específica de ese lanzamiento.

El formato consiste en una serie de entradas como estas:

package (version) distribution(s); urgency=urgency [optional blank line(s), stripped]

package y version son el nombre del paquete fuente y del número de versión.

distribution(s) listan las distribuciones donde esta versión debería ser instalada cuando sea subida - esto será compiado al campo Distribution en el archivo .changes. ver Distribución, Sección 5.6.14

urgency es el valor del campo Urgency en el archivo .changes para ser subido (ver Urgencia, Sección 5.6.17). No es posible especificar una urgencia conteniendo comas; las comas son usadas para separar los ajustes keyword=value en el fomato changelog del dpkg. (Aunque solo hay una keyword útil, urgency). 15

Los detalles del cambio de hecho pueden ser cualquier serie de líneas comenzando al menos con dos espacios, pero convencionalmente cada cambio comienza con un asterisco y un espacio de saparación y las líneas de continuación están alineadas con el texto de arriba. Si se desea, las líneas en blanco se pueden usar aquí para separar grupos de cambios.

Si esta actualización resuelve bugs que hayan sido grabados por el Sistema de seguimiendo de errores [Bug Tracking System (BTS)], deben de ser automáticamente cerrados con la inclusión de este paquete en el archivo de Debian incluyendo la cadena: closes: Bug#nnnnn en los detalles de cambio. 16 Esta informcón es transportada por medio del campo Closes en el archivo .changes (ver Closes, Sección 5.6.17).

El nombre y el correo del mantenedor usado en el changelog deberían de ser los detalles de la persona que ha subido esta versión. Ellos no tienen que ser necesariamente los mantenedores usuales del paquete. Esta información será copiada al campo Changed-By en el archivo .changes (ver Changed-By, Sección 5.6.4), y más tarde usado para enviar una confirmación cuando la subida haya sido instalada.

La fecha, date debe ir en formato RFC822 17; Esto debería incluir la zona horaria especificada numéricamente, con el nombre de la zona horaria u opcionalmente la abreviación, presentada como un comentario entre paréntisis.

La primera línea de título ("title") con el nombre del paquete debería de comenzar en el margen de la izquierda; la línea acplada ("trailer") con los detalles del mantenedor y la fecha debe de ir precedida exáctamente de un espacio. Los detalles del mantenedor y la fecha deben de ir separados exáctamente por dos espacios.

Para más información sobre la colocación de los archivos del changelog dentro de los paquetes binarios, vea Archivos Changelog, Sección 12.7.

4.4.1 Formatos alternativos de changelog

En paquetes no experimentales, debes usar un formato para el debian/changelog que esté soportado por la versión más reciente del dpkg.

Es posible usar un formato diferente del estandar proporcionando un conversor para el formato que deseas usar. El conversor debe tener un API compatible con lo que dpkg-genchanges y dpkg-gencotrol esperan, y no debería de interactuar con el usuario de ninguna manera. 18

4.5 Interceptación de errores en el makefile

Cuando make invoca a un comando en un makefile (incluyendo los makefiles subidos en su paquete y debian/rules), lo hace mediante sh. Esto significa que sh tiene unas malas características de gestión de errores: si incluye un pequeño script como uno de los comandos en tu makefile, podrás ver que si haces nada los errores no son detectados y make alegremente continuará después de los problemas.

Cada vez que pongas más de un comando shell (esto incluye los loops) en un comando del makefile tienes que estar seguro que los errores son cazados. Para comandos complejos simples, como un cambio de directorio y después correr un programa, usando && mejor que el punto y coma es suficiente. Para comandos más complejos incluyendo muchos loops y condiciones deberías de incluir un set -e command separado al comienzo de cada comando makefile el cual es uno de esos pequeños shell scripts.

4.6 Marcas Temporales

Los mantenedores deben preservar los tiempos modificación de los ficheros fuentes subidos en el paquete, tanto como sea razonablemente posible. 19

4.7 Restricciones de objetos en paquetes fuente

El paquete fuente no puede contener ningún enlace duro 20, archivos especiales de dispositivos, sockets o archivos setuid o setgid. 21

4.8 Script de construcción principal

Este archivo debe ser un makefile ejecutable, y contener las recetas específicas para compilar cada paquete y construir los paquetes binarios desde el código.

Debe comenzar con la línea #!/usr/bin/make -f, así puede ser invocado por su nombre mejor que invocando a make explícitamente.

Desde un script debian/rules interactivo, se hace imposible el auto-compilar el paquete y también hace dificil a otras personas el reproducir el mismo paquete binario, todos los objetivos requeridos DEBEN ser no-interactivos. Como mínimo, los objetivos requeridos son aquellos llamados por dpkg-buildpackage, a saber, clean, binary, binary-arch, binary-indep, y build. Esto también sigue que cualquier objetivo que dependa de estos objetivos también tiene que ser no-interactivo.

Los objetivos son como sigue (requerido a menos que esté indicado de otra forma)

build

faltan estos 4

build-arch (opcional), build-indep (opcional)

binary, binary-arch, binary-indep

clean

get-orig-source (optional)

Los objetivos de contrucción, binario y clean deben de ser invocados con el directorio actual siendo este el directorio superior del paquete.

Objetivos adicionales pueden existir en debian/rules, así como interfaces publicados o indocumentados o para el uso interno del paquete.

Las arquitecturas que construimos y compilamos "para" son determinadas por variables make usando la utilidad dpkg-architecture. You can determine la arquitectura Debian y la cadena de especificaciones de la arquitectura al estilo GNU para la máquinaconstructora (el tipo de máquina en la que construimos) como también para la máquina destino (la máquina para la cual estamos construyendo). Aquí hay una lista de las variables make soportadas.

donde * es cada BUILD

La compatibilidad hacia atrás puede ser proporcionada en el archivo rules poniendo las variables necesarias a valores por defecto adecuados; por favor remitase a la documentación de dpkg-architecture para más detalles.

Es importante entender que la cadena DEB_*_ARCH solo determina cual es la arquitectura Debian para la cual estamos construyendo. Esto no debería ser usado para obtener la CPU o información del sistema; las variables de estilo GNU deberían de ser usadas para eso.

4.9 Sustitución de Variables: debian/substvars

Cuando dpkg-gencontrol, dpkg-genchanges y dpkg-source generan archivos de control, llevan a cabo la sustitución de variables en su salida justo antes de escribirlo. La sustitución de variables tienen la forma ${variable}. El archivo opcional debian/substvars contiene la sustitución de variables que se usarán; las variables pueden ser establecidas directamente desde el debian/rules usando la opción -V a los comandos de empaquetado de fuentes, y ciertas variables predefinidas también están disponibles.

El archivo debian/substvars es usualmente generado y modificado dinámicamente por los objetivos de debian/rules, en cuyo caso debe de ser eliminado por el objetivo.

Ver dpkg-source(1) para tener detalles completos sobre las sustituciones de variables fuente, incluyendo el formato de debian/substvars

4.10 Lista de ficheros generados: debian/files

Este archivo no es una parte permanente del árbol fuente; es usado durante la construcción de paquetes para grabar cuales son los archivos que van a ser generados. dpkg-genchanges lo usa cuando genera un archivo .changes

No debería de existir en un paquete exportado, y tampoco (y ningún archivo de backup o archivos temporales tales como files.new24) debería de ser eliminado por el objetivo clean. Esto puede ser también inteligente para asegurar un comienzo limpio limpiándolo al comienzo del objetivo binario.

Cuando dpkg-gencontrol se ejecuta para un paquete binario, añade una entrada al debian/files para el archivo .deb el cual será creado cuando dkpg-deb --build es ejecutado para ese paquete binario. Así que para la mayoría de los paquetes todo lo que necesita hacer con este archivo es eliminarlo en el objetivo clean.

Si al subir un paquete incluye archivos además de los paquetes fuentes y cualquier paquete binario cuyos archivos de control han sido creados con dpkg-gencontrol entonces deberían de ser colocados en el directorio raiz del nivel más alto del paquete y dpkg-distaddfile debería ser invocado para añadir el archivo a la lista en debian/files.