NOMBRE¶
deb-src-control - Formato del fichero de control maestro de paquetes fuente de
Debian
SINOPSIS¶
control
DESCRIPCIÓ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 <ffdez@tal.com>». 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 <debian-dpkg@lists.debian.org>
# 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 <hertzog@debian.org>
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.
VÉASE TAMBIÉN¶
deb-control(5),
deb-version(5),
dpkg-source(1)
TRADUCTOR¶
Rudy Godoy <rudy@kernel-panik.org>, Rubén Porras
<nahoo@inicia.es>, Bruno Barrera C. <bruno.barrera@igloo.cl>,
Carlos Izquierdo <gheesh@ertis.net>, Esteban Manchado y NOK. Debian L10n
Spanish <debian-l10n-spanish@lists.debian.org>.
Revisiones por Santiago Vila <sanvila@unex.es>, Javier
Fernández-Sanguino, Rubén Porras, Luis Uribe y Omar Campagne.