SINOPSIS
controlDESCRIPCIÓN
Cada paquete fuente de Debian incluye el fichero maestro «control», que contiene al menos 2 párrafos separados por una línea en blanco. El primer párrafo menciona la información del paquete fuente en general, mientras que el siguiente párrafo describe un único paquete binario. Cada párrafo incluye al menos un campo. Un campo empieza con un nombre de campo, como Package o Section (sin diferenciación entre mayúsculas y minúsculas), seguido de dos puntos, el cuerpo del campo y una nueva línea. Se permiten campos de varias líneas, pero cada línea adicional, sin nombre de campo, debe tener al menos un espacio al principio de la línea. Habitualmente, las herramientas unen un campo de varias líneas en una sola (a excepción del campo Description, a continuación). Para insertar líneas en blanco en un campo de varias líneas, inserte un punto a continuación del espacio. Las líneas que comienzan con «#» se tratan como comentarios.CAMPOS DE FUENTE
- Source: nombre-del-paquete-fuente (obligatorio)
-
El valor de este campo es el nombre del paquete fuente, y debería coincidir
con el nombre del paquete fuente en el fichero «debian/changelog». Un nombre
de paquete solo puede consistir de minúsculas (a-z), dígitos (0-9), signos
de suma (+), resta (-) y puntos (.). Los nombres de paquete deben tener una
longitud mínima de 2 caracteres, y empezar con un carácter alfanumérico.
- Maintainer: nombre-completo correo-electrónico (obligatorio)
-
Debería tener un formato del tipo «Fernando Fernández
<[email protected]>». Habitualmente hace referencia a la persona que ha
creado el paquete del programa, y no a su autor original.
- Uploaders: nombre-completo correo-electrónico
-
Enumera los nombres y direcciones de correo electrónico de los
co-responsables del paquete, con el mismo formato que el campo
«Maintainer». Varios co-responsables se deben separar con comas.
- Standards-Version: cadena-de-caracteres-con-el-número-de-versión
-
Esto documenta la versión más reciente de los estándares con la que cumple
este paquete (que consiste del manual de Normas de Debian y textos
mencionados en el paquete debian-policy).
- DM-Upload-Allowed: yes|no
-
Este campo indica si los responsables de Debian incluidos en los campos
«Maintainer» u «Uploaders» pueden enviar el paquete al archivo. El valor
predefinido es «no».
- Homepage: url
-
La dirección url de la página oficial del autor original.
- Bugs: url
-
La dirección url del sistema de seguimiento de fallos de este paquete. El
formato usado actualmente es: bts-type://bts-address, por ejemplo
debbugs://bugs.debian.org. Habitualmente, este campo no es necesario.
- Vcs-*: url
-
La dirección url del repositorio del sistema de control de versiones
utilizado para desarrollar este paquete. Los permitidos actualmente son
Arch, Bzr (Bazaar), Cvs, Darcs, Git, Hg (Mercurial),
Mtn (Monotone) y Svn (Subversion). Habitualmente, este campo apunta a
la última versión del paquete, como la rama principal o «trunk».
- Vcs-Browser: url
-
La dirección url de la interfaz web para explorar el repositorio del
sistema de control de versiones.
- Origin:nombre
-
El nombre de la distribución origen del paquete. Habitualmente, este campo
no es necesario.
- Section:sección
-
Es un campo general que define la categoría del paquete basándose en el
programa que instala. Algunas secciones comunes son «utils», «net», «mail»,
«text», «x11» etc.
- Priority:prioridad
-
Define la importancia del paquete en relación con todo el sistema. Algunas
prioridades comunes son «required», «standard», «optional», «extra» etc.
En Debian los campos Section y Priority tienen definidos un conjunto reducido de valores válidos de acuerdo al Manual de Normas de Debian. Puede obtener una lista completa de estos valores con la última versión del paquete debian-policy.
- Build-Depends: lista-de-paquetes
-
Una lista de paquetes que se deben instalar y configurar para poder
construir el paquete fuente. Incluir una dependencia en esta lista tiene el
mismo efecto que incluirlo en los dos campos Build-Depends-Arch y
Build-Depends-Indep, con el efecto añadido de que se utiliza para
construcciones solo de las fuentes.
- Build-Depends-Arch: lista-de-paquetes
-
Idéntico a Build-Depends, pero solo se requieren al construir paquetes
independientes de la arquitectura, en cuyo caso también se instalan los
paquetes Build-Depends. Esta campo se introdujo en la versión 1.16.4 de
dpkg; para construir con versiones anteriores de dpkg, utilice
Build-Depends.
- Build-Depends-Indep: lista-de-paquetes
-
Idéntico a Build-Depends, pero es necesario solo al construir paquetes
independientes de la arquitectura, en cuyo caso también se instalan los
paquetes Build-Depends.
- Build-Conflicts: lista-de-paquetes
-
Una lista de paquetes que no deben estar instalados al construir el paquete,
por ejemplo porque interfieren con el sistema de construcción
utilizado. Incluir una dependencia en esta lista tiene el mismo efecto que
incluirla en Build-Conflicts-Arch y Build-Conflicts-Indep, con el
efecto añadido de que se utiliza para construcciones solo de las fuentes.
- Build-Conflicts-Arch: lista-de-paquetes
-
Identicó a Build-Conflicts, pero solo al construir paquetes dependientes
de la arquitectura. Este campo se introdujo en la versión 1.16.4 de dpkg;
para construir con versiones anteriores de dpkg, utilice Build-Conflicts.
- Build-Conflicts-Indep: lista-de-paquetes
-
Idéntico a Build-Conflicts, pero solo al construir paquetes
independientes de la arquitectura.
La sintaxis de los campos Build-Depends, Build-Depends-Arch y Build-Depends-Indep es una lista de grupos de paquetes alternativos. Cada grupo es una lista de paquetes separados por una barra vertical «|». Los grupos se separan mediante comas. Las comas se leen como «AND», y las barras verticales como «OR», lo cual se evalúa antes que «AND». Cada nombre de paquete puede ir seguido de un número de versión definido entre paréntesis y la especificación de la arquitectura entre corchetes.
La sintaxis de Build-Conflicts, Build-Conflicts-Arch y Build-Conflicts-Indep es una lista separada por comas de nombres de paquete, en el que la coma se lee como «AND». No se permite definir paquetes alternativos utilizando una barra vertical «|». Cada nombre de paquete puede ir seguido de un número de versión definido entre paréntesis y la especificación de la arquitectura entre corchetes.
Un número de versión puede empezar con «>>», en cuyo caso cualquier versión posterior encajaría, siendo posible omitir el número de revisión de Debian (separado por un guión). Las relaciones de versión válidas son «>>» para «mayor que», «<<» para «menor que»,«>=» para «mayor o igual que», «<=» para «menor o igual» y «=» para «igual que».
Una especificación de arquitectura consiste de uno o más nombres de arquitectura, separados por espacios en blanco. Un signo de exclamación puede preceder a cualquier de estos nombres, con el significado de «NOT».
Tenga en cuenta que los paquetes del conjunto de paquetes build-essential se pueden omitir, y que es casi imposible declarar conflictos de construcción frente a ellos. Puede encontrar una lista de estos paquetes en el paquete build-essential.
CAMPOS BINARIOS
Tenga en cuenta que los campos Priority, Section y Homepage también se pueden incluir en una párrafo binario para sustituir el valor global del paquete fuente.
- Package: nombre-del-paquete-binario (obligatorio)
-
Este campo se utiliza para nombrar a un paquete binario. Se aplican las
mismas restricciones que afectan al nombre del paquete fuente.
- Architecture: arch|all|any (obligatorio)
-
La arquitectura especifica el tipo de hardware sobre el que se ejecuta este
paquete. Para paquetes que se ejecutan en todas las arquitecturas, utilice
el valor any. Para paquetes independientes de la arquitectura, como
scripts de intérprete de órdenes, de Perl, o documentación, utilice el valor
all. Para limitar los paquetes a un conjunto de arquitecturas defina los
nombres de arquitectura separados por espacio. También es posible utilizar
comodines de arquitectura en esta lista. Para más información consulte
dpkg-architecture(1).
- Package-Type: deb|udeb
-
Este campo define el tipo de paquete. «udeb» se utiliza para paquetes de
tamaño limitado utilizados por el instalador de Debian. «deb» es el valor
predefinido cuando se omite el campo. Se añadirán más tipos en el futuro.
- Subarchitecture: valor
- Kernel-Version: valor
-
Installer-Menu-Item: valor
debian-installer utiliza estos campos, y habitualmente no son
necesarios. Para más información consulte
«/usr/share/doc/debian-installer/devel/modules.txt» del paquete
debian-installer.
- Essential: yes|no
- Multi-Arch: same|foreign|allowed
- Tag: lista-de-etiquetas
-
Description: descripción-corta (obligatorio)
Estos campos se describen en la página de manual deb-control(5), ya que
se copian de forma literal al fichero «control» del paquete binario.
- Depends: lista-de-paquetes
- Pre-Depends: lista-de-paquetes
- Recommends: lista-de-paquetes
- Suggests: lista-de-paquetes
- Breaks: lista-de-paquetes
- Enhances: lista-de-paquetes
- Replaces: lista-de-paquetes
- Conflicts: lista-de-paquetes
- Provides: lista-de-paquetes
-
Built-Using: lista-de-paquetes
Estos campos declaran relaciones entre paquetes. Se describen en la página de manual deb-control(5) y el paquete debian-policy.
CAMPOS DEFINIDOS POR USUARIO
El fichero de control permite añadir campos definidos por usuario. Las herramientas ignoran estos campos. Si quiere que los campos se copien a los ficheros de salida, como los paquetes binarios, tendrá que utilizar un esquema de denominación predefinido: los campos deben empezar con «X», seguido de una o más de las letras BCS y un guión. Si se utiliza la letra B, el campo aparecerá en el fichero de control del paquete binario, consulte deb-control(5). Si utiliza la letra S, aparecerá en el fichero de control de paquete fuente generado por dpkg-source(1). Si utiliza la letra C, aparecerá en el fichero de control de envío («.changes»). Tenga en cuenta que los prefijos «X[BCS]-» se eliminan cuando los campos se copian a los ficheros de salida. Un campo XC-Approved-By aparece como Approved-By en el fichero «.changes», y no aparecerá en los ficheros de control de paquete fuente o binario.Tenga en cuenta que estos campos definidos por usuario utilizan el espacio de nombres global, que en el futuro podría entrar en conflicto con campos oficialmente reconocidos. Para evitar esta situación potencial, puede prefijar estos campos con Private-, como por ejemplo XB-Private-New-Field, que como efecto añadido impide que dpkg-deb envíe una advertencia de campo desconocido.
EJEMPLO
# Comment Source: dpkg Section: admin Priority: required Maintainer: Dpkg Developers <[email protected]> # this field is copied to the binary and source packages XBS-Upstream-Release-Status: stable Homepage: http://wiki.debian.org/Teams/Dpkg Vcs-Browser: http://git.debian.org/?p=dpkg/dpkg.git Vcs-Git: git://git.debian.org/git/dpkg/dpkg.git Standards-Version: 3.7.3 Build-Depends: pkg-config, debhelper (>= 4.1.81), libselinux1-dev (>= 1.28-4) [!linux-any] Package: dpkg-dev Section: utils Priority: optional Architecture: all # this is a custom field in the binary package XB-Mentoring-Contact: Raphael Hertzog <[email protected]> Depends: dpkg (>= 1.14.6), perl5, perl-modules, cpio (>= 2.4.2-2), bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl Recommends: gcc | c-compiler, build-essential Suggests: gnupg, debian-keyring Conflicts: dpkg-cross (<< 2.0.0), devscripts (<< 2.10.26) Replaces: manpages-pl (<= 20051117-1) Description: Debian package development tools This package provides the development tools (including dpkg-source) required to unpack, build and upload Debian source packages. . Most Debian source packages will require additional tools to build; for example, most packages need make and the C compiler gcc.
TRADUCTOR
Rudy Godoy <[email protected]>, Rubén Porras <[email protected]>, Bruno Barrera C. <[email protected]>, Carlos Izquierdo <[email protected]>, Esteban Manchado y NOK. Debian L10n Spanish <[email protected]>.Revisiones por Santiago Vila <[email protected]>, Javier Fernández-Sanguino, Rubén Porras, Luis Uribe y Omar Campagne.