Capítulo 3 - Paquetes binarios

La distribución GNU/Linux Debian está basada en el sistema de gestión de paquetes Debian, llamado dpkg. Luego todos los paquetes en la distribución Debian debe ser suministrados en el formato de archivo .deb.

3.1 Nombre del paquete

Cada paquete debe tener un nombre que es único dentro del archivo Debian.

El nombre del paquete está incluido en el campo de control Package, cuyo formato se describe en 'Paquete', Sección 5.6.6. El nombre del paquete forma parte también del nombre del archivo .deb.

3.2 La versión de un paquete

Cada paquete tiene un número de versión registrado en el campo Version del archivo de control, descrito en 'Versión', Seción 5.6.11.

El sistema de gestión de paquetes impone un orden sobre los números de versión, de manera que pueda establecerse si los paquetes están siendo actualizados o degradados y que los programas que hacen uso del sistema de gestión de paquetes puedan establecer si un paquete que encuentran disponible es más reciente que el instalado en el sistema. El formato de número de versión tiene la parte más significativa (en cuanto a comparación) al principio.

Si un paquete tiene números problemáticos, deben ser convertidos a una forma correcta para su uso en este campo Version.

3.2.1 Números de versión basados en fechas

En general, los paquetes Debian deberían usar los mismos números de versión que las fuentes "aguas arriba".

Sin embargo, en algunos casos donde el número de versión "aguas arriba" está basado en una fecha (p.e. una versión en desarrollo tomada como 'instantánea') el sistema de gestión de paquetes no puede manejar estos números de versión sin referencia temporal. Por ejemplo, dpkg considerará "96May01" mayor que "96Dec24".

Para evitar tener que utilizar referencias temporales para cada versión "aguas arriba", la porción del número de versión basado en fecha debe ser cambiado en tales casos al siguiente formato: "19960501", "19961224". Es cosa del encargado del paquete si él/ella quiere molestar al encargado "aguas arriba" para cambiar esos números también.

Note que otros formatos basados en fechas que son interpretados correctamente por el sistema de gestión de paquetes no deben ser cambiados.

Los paquetes nativos Debian (esto es, los paquetes que han sido escritos específicamente para Debian) cuyos números de versión incluyan fechas siempre deben utilizar el formato "AAAAMMDD".

3.3 El encargado de un paquete

Cada paquete debe tener un encargado Debian (el encargado puede ser una persona o un grupo de personas asequibles por una dirección de correo común, tal como una lista de correo). El encargado es responsable de asegurar que el paquete está situado en las distribuciones apropiadas.

El encargado debe estar especificado en el campo de control Maintainer con su nombre correcto y una dirección de correo funcional. Si una persona se encarga de varios paquetes, él/ella debería evitar tener diversas formas de su nombre y dirección de correo en los campos Maintainer de esos paquetes.

El formato del campo de control Maintainer se describe en Encargado, Sección 5.6.2.

Si el encargado de un paquete abandona el proyecto Debian, el grupo "Debian QA" packages@qa.debian.org toma el mantenimiento del paquete hasta que alguien se ofrece voluntario para esa tarea. Estos paquetes se denominan paquetes huérfanos. [5]

3.4 La descripción de un paquete

Cada paquete Debian debe tener una descripción extendida almacenada en el campo apropiado del registro de control. La información técnica acerca del formato del campo Description está en Descripción, Sección 5.6.12.

La descripción debería describir el paquete (el programa) a un usuario (administrador del sistema) que nunca lo ha visto antes, de manera que tenga suficiente información para decidir si quiere instalarlo. Esta descripción no debería ser copiada literalmente de la documentación del programa.

Ponga la información importante primero, tanto en la sinopsis como en la descripción extendida. A veces sólo se mostrará la primera parte de la sinopsis o de la descripción. Ud. puede asumir que normalmente habrá una manera de ver toda la descripción extendida.

La descripción debería dar también información acerca de las dependencias significativas y los conflictos entre este paquete y otros, de forma que el usuario sepa por qué se declararon esas dependencias y conflictos.

Las instrucciones para configurar o usar el paquete no deberían estar incluidas (para eso son los libretos de instalación, las páginas del manual, los archivos info, etc.) Las declaraciones de copyright, autoría y otros aspectos administrativos tampoco deberían incluirse (para eso es el archivo copyright).

3.4.1 La sinopsis de una línea

La sinopsis de una única línea debería mantenerse breve - por debajo de 80 caracteres.

No incluya el nombre del paquete en la línea de sinopsis. El programa ya sabe cómo mostrarlo y Ud. no necesita hacerlo. Recuerde que en muchas ocasiones el usuario podría ver únicamente la línea de sinopsis - hágala tan informativa como pueda.

3.4.2 La descripción extendida

No trate de continuar la sinopsis de una línea en la descripción extendida. Eso no funcionará correctamente cuando se muestre la descripción completa, y no tiene sentido donde se tiene acceso al resumen (la sinopsis de una línea).

La descripción extendida debería describir qué hace el paquete y cómo se relaciona con el resto del sistema (en términos de cuál subsistema forma parte, por ejemplo).

El campo de descripción necesita tener sentido para cualquiera, incluso gente que no tiene idea acerca de las cosas con las que trata el paquete. [6]

3.5 Dependencias

Cada paquete debe especificar la información de sus dependencias de los otros paquetes que se requieren para que el primero funcione correctamente.

Por ejemplo, se debe proveer una nota de dependencia para cualquier biblioteca de funciones compartida requerida por un binario ejecutable enlazado dinámicamente en un paquete.

Los paquetes no requieren declarar ninguna dependencia que tengan en otros paquetes que son marcados Essential (ver más abajo), y no deberían hacerlo a menos que dependan de una versión particular de aquel paquete.

A veces, un paquete requiere antes de ser instalado que otro paquete sea instalado y configurado. En este caso, Ud. debe especificar una nota Pre-Depends para el paquete.

Ud. no debería especificar una nota Pre-Depends para un paquete antes de que esto haya sido discutido en la lista de correo debian-devel y se haya alcanzado un consenso al respecto.

El formato de los campos de control de interrelaciones del paquete se describe en Declaración de relaciones entre paquetes, Capítulo 7.

3.6 Paquetes virtuales

A veces existen varios paquetes que ofrecen más-o-menos la misma funcionalidad. En este caso, es útil definir un paquete virtual cuyo nombre describa esa funcionalidad común. (Los paquetes virtuales sólo existen lógicamente, no físicamente; por eso se llaman virtuales). Los paquetes con esa función particular conforman entonces el paquete virtual. Por lo tanto, cualquier otro paquete que requiera esa función puede depender simplemente del paquete virtual sin tener que especificar individualmente todos los paquetes posibles.

Todos los paquetes deberían utilizar nombres de paquete virtual donde eso sea apropiado, y permitir crear nuevos si fuese necesario. No deberían utilizar nombres de paquete virtual (excepto privadamente, entre un grupo cooperativo de paquetes) a menos que haya sido acordado y aparezcan en la lista de nombres de paquetes virtuales. (Ver también ?[http://pendiente[Paquetes virtuales - Provides, Sección 7.4).

La última versión de la lista autorizada de nombres de paquetes virtuales se puede encontrar en el paquete debian-policy. También se puede obtener en las réplicas web de Debian en /doc/packaging-manuals/virtual-package-names-list.txt

El procedimiento para actualizar la lista se describe en el prefacio de la lista.

3.7 Sistema base

El sistema base (base system) es un subconjunto mínimo del sistema GNU/Linux Debian que se instala antes que cualquier otra cosa en un sistema nuevo. Por ello, a muy pocos paquetes se les permite ir en la sección base para mantener bajo el uso requerido de disco.

La mayoría de estos paquetes tendrán el valor de prioridad required o al menos important, y muchos de ellos estarán marcados essential (ver más abajo)-

3.8 Paquetes esenciales

Algunos paquetes llevan la marca essential (esencial) para un sistema utilizando el campo del archivo de control Essential. El formato del campo de control Essential se describe en Esencial, Sección 5.6.8.

Ya que estos paquetes no se pueden remover fácilmente (uno debe especificar la opción force a dpkg para poder hacerlo), esta marca no se debe utilizar a menos que sea absolutamente necesario. Un paquete de biblioteca de funciones compartidas no debe marcarse essential; las dependencias prevendrán su remoción prematura, y necesitamos ser capaces de removerlo cuando se haga anticuado.

Ya que dpkg no evitará la actualización de otros paquetes mientras un paquete essential esté en estado desconfigurado, todos los paquetes essential deben proveer toda su funcionalidad clave incluso cuando no estén configurados. Si el paquete no puede satisfacer este requerimiento no debe ser marcado como essential, y todo paquete que dependa de este paquete debe tener campos de dependencia explícitos según sea apropiado.

Ud. no debe marcar ningún paquete essential antes que esto haya sido discutido en la lista de correo debian-devel y se haya alcanzado un consenso al respecto.

3.9 Tareas

El proceso de instalación Debian permite al usuario elegir entre un número de tareas comunes para las cuales un sistema Debian puede ser utilizado. Seleccionar una tarea con tasksel hace que se instalen un conjunto de paquetes que son útiles para la ejecución de esa tarea.

Este conjunto de paquetes está formado por todos los paquetes disponibles que tienen el nombre de la tarea seleccionada en el campo Task de su archivo de control. El formato de este campo es una lista de tareas, separada por comas.

Ud. no debería marcar ningún paquete como perteneciente a una tarea antes que esto haya sido discutido en la lista de correo debian-devel y se haya alcanzado un consenso al respecto.

Debido a la existencia de terceras partes (y razones históricas), tasksel también permite construir tareas basadas en paquetes de tareas. Estos son paquetes cuyos nombres comienzan con task-. Los paquetes de tareas no deberían incluirse en el archivo Debian.

3.10 Libretos (scripts) del encargado

Los libretos de instalación del paquete deberían evitar producir salidas que el usuario no necesita ver y deberían confiar en dpkg para evitar el aburrimiento de un usuario que esté instalando muchos paquetes. Esto quiere decir, entre otras cosas, utilizar la opción --quiet en install-info.

Los errores que ocurran durante la ejecución de un libreto de instalación deben ser revisados y la instalación no debe continuar después de un error.

Note que en general la Sección 10.4, Libretos se aplica también a los libretos del encargado del paquete.

Ud. no debería utilizar dpkg-divert en un archivo que pertenece a otro paquete sin antes consultar al encargado de ese paquete.

Todos los paquetes que proporcionan una instancia de un nombre de comando común (o, en general, un nombre de archivo) deberían utilizar generalmente update-alternatives, de forma que puedan ser instalados conjuntamente. Si no se utiliza update-alternatives entonces cada paquete debe usar Conflicts para asegurarse que otros paquetes sean desinstalados. (En este caso podría ser apropiado especificar un conflicto contra versiones anteriores de algo que previamente no había utilizado update-alternatives; esta es una excepción a la regla habitual de que se deben evitar los conflictos entre versiones).

3.10.1 Diálogos en los libretos del encargado

Los libretos del encargado del paquete pueden inquirir al usuario si es necesario. El diálogo debería efectuarse por medio de un programa, tal como debconf el cual se adecúa a la especificación de gestión Configuración Debian, versión 2 o mayor. Interrogar al usuario por otros medios, como a mano 7 se desaprueba actualmente.

La especificación de gestión Configuración Debian está incluida en los archivos debconf_specification en el paquete debian-policy. También está disponible en las réplicas web de Debian en /doc/packaging-manuals/debconf_specification.html.

Los paquetes que utilizan la especificación de gestión Configuración Debian pueden contener un libreto config y un archivo templates (plantillas) en su archivo de control [8]. El libreto config podría ejecutarse antes del libreto preinst, y antes de desempaquetar el paquete o de que cualquiera de sus dependencias o pre-dependencias estén satisfechas. Por lo tanto, debe funcionar utilizando solamente las herramientas presentes en los paquetes essential. [9]

Los paquetes deberían tratar de minimizar la cantidad de diálogo que necesitan, y deberían asegurarse de que al usuario se le hará una pregunta sólo una vez. Esto quiere decir que los paquetes deberían tratar de utilizar los archivos de configuración compartidos apropiados (tales como /etc/papersize y /etc/news/server), y las variables debconf compartidas en lugar de que cada uno pida su propia lista de piezas de información.

Esto también quiere decir que una actualización no debería hacer las mismas preguntas de nuevo, a menos que el usuario haya utilizado dpkg --purge para remover la configuración del paquete. Las respuestas a las preguntas de configuración deberían ser almacenadas en un lugar apropiado en /etc para que el usuario pueda modificarlas, y debería documentarse cómo se hizo eso.

Si un paquete tiene que pasar al usuario una pieza de información vitalmente importante (tal como "no me ejecute como estoy, debe editar primero los siguientes archivos de configuración o arriesga que su sistema emita mensajes mal formateados"), debería mostrar esto en el libreto config o postinst y pedir al usuario pulsar la tecla 'return' (intro?) para admitir el mensaje. Los mensajes de Copyright no cuentan como vitalmente importantes (residen en /usr/share/doc/package/copyright); ni tampoco las instrucciones de cómo usar un programa (estas deberían estar en la documentación en línea, donde todos los usuarios puedan verlas).

Cualquier diálogo necesario debería estar confinado casi siempre a los libretos config o postinst. Si se hace en postinst, debería estar protegido con un condicional de manera que no ocurra un diálogo innecesario si falla la instalación de un paquete y postinst es invocado con abort-upgrade, abort-remove o abort-deconfigure.