deb-src-control
Section: dpkg suite (5)
Updated: 1970-01-01
Page Index
NOME
deb-src-control - formato Debian de ficheiro de controle mestre de pacotes
fonte
SINOPSE
debian/control
DESCRIÇÃO
Each Debian source package contains the master «
debian/control» file, and
its
deb822(5) format is a superset of the
control file shipped in
Debian binary packages, see
deb-control(5).
This file contains at least 2 paragraphs, separated by a blank line. The
first paragraph lists all information about the source package in general,
while each following paragraph describes exactly one binary package. Each
paragraph consists of at least one field. A field starts with a fieldname,
such as Package or Section (case insensitive), followed by a colon,
the body of the field (case sensitive unless stated otherwise) and a
newline. Multi-line fields are also allowed, but each supplementary line,
without a fieldname, should start with at least one space. The content of
the multi-line fields is generally joined to a single line by the tools
(except in the case of the Description field, see below). To insert empty
lines into a multi-line field, insert a dot after the space. Lines starting
with a '#' are treated as comments.
CAMPOS DE FONTE
- Source: source-package-name (necessário)
-
O valor deste campo é o nome do pacote fonte, e deve corresponder ao nome do
pacote fonte no ficheiro debian/changelog. O nome de um pacote deve
consistir apenas de letras minúsculas (a-z), dígitos (0-9), e dos sinais
mais (+) e menos (-) e de pontos (.). Os nomes dos pacotes devem ter pelo
menos dois caracteres de comprimento e têm de começar com um caractere
alfanumérico minúsculo (a-z0-9).
- Maintainer: fullname-email (recomendado)
-
Deverá estar no formato «Joe Bloggs <jbloggs@foo.com>», e refere-se
à pessoa que mantém actualmente o pacote, e não o autor do software nem ao
empacotador original.
- Uploaders: fullname-email
-
Lista todos os nomes e endereços de email de co-maintainers do pacote, no
mesmo formato que o campo Maintainer. Vários co-maintainers devem ser
separados por uma vírgula.
- Standards-Version: version-string
-
Isto documenta a versão mais recente dos standards de política da
distribuição com que este pacote está em conformidade.
- Description short-description
-
- long-description
-
O formato da descrição do pacote fonte é um sumário breve e curto na
primeira linha (após o campo Description). As linhas seguintes devem ser
usadas para uma descrição longa e mais detalhada. Cada linha da descrição
longa tem de ser precedida com um espaço, e as linhas em branco na descrição
longa têm de conter um único '.' a seguir ao espaço que precede.
- Homepage: url
-
O URL da página inicial do projecto do autor original
- Bugs: url
-
O url do sistema de acompanhamento de bugs deste pacote. O formato usado
actualmente é bts-type://bts-address, como
debbugs://bugs.debian.org. Este campo geralmente não é necessário.
- Rules-Requires-Root: no|binary-targets|impl-keywords
-
Este campo é usado para indicar se o campo debian/rules requer
privilégios de (fake)root para correr alguns dos seus alvos, e se sim
quando.
-
- no
-
Os alvos binários não irão requerer (fake)root de todo.
- binary-targets
-
Os alvos binários devem ser sempre corridos sob (fake)root. Este é a
predefinição quando o campo é omitido, adicionar o campo com um
binary-targets explícito quando não estritamente necessário, marca-o como
tendo sido analisada para este requerimento.
- impl-keywords
-
Isto é uma lista de palavras-chave separadas por espaços que define quando
(fake)root é requerido.
Palavras chave consistem de namespace/cases. A parte namespace não
pode conter ``/'' ou espaços em branco. A parte cases não pode conter
espaços em branco. Mais ainda, ambas partes têm de consistir inteiramente de
caracteres ASCII de escrita.
Cada ferramenta/pacote irá definir um espaço-nome com o nome dela própria e
disponibilizar um número de casos onde (fake)root é necessário. (Veja
``Implementação de palavras-chave fornecidas'' em rootless-builds.txt).
Quando o campo está definido para uma das impl-keywords, o compilador irá
expor uma interface que é usada para correr um comando sob (fake)root. (Veja
``Gain Root API'' em rootless-builds.txt.)
-
- Testsuite: name-list
-
- Testsuite-Triggers: package-list
-
Estes campos estão descritos no manual do dsc(5), pois eles são gerados a
partir de informação inferida de debian/tests/control ou copiada
literalmente para o ficheiro de controle da fonte.
- Vcs-Arch: url
-
- Vcs-Bzr: url
-
- Vcs-Cvs: url
-
- Vcs-Darcs: url
-
- Vcs-Git: url
-
- Vcs-Hg: url
-
- Vcs-Mtn: url
-
- Vcs-Svn: url
-
O url do repositório do Sistema de Controlo de Versão usando para manter
este pacote. Actualmente suportados são Arch, Bzr (Bazaar), Cvs,
Darcs, Git, Hg (Mercurial), Mtn (Monotone) e Svn
(Subversion). Geralmente esta campo aponta par aa versão mais recente do
pacote, tal como o ramal principal ou o ``trunk''.
- Vcs-Browser: url
-
O url da uma interface web para explorar o repositório do Sistema de
Controlo de Versão.
- Origin: name
-
O nome da distribuição de onde este pacote é originário. Normalmente este
campo não é necessário.
- Section: section
-
Este é um campo geral que dá ao pacote uma categoria baseada no software que
ele instala. Algumas secções comuns são utils, net, mail, text,
x11, etc.
- Priority: priority
-
Define a importância deste pacote relativamente ao sistema como um
todo. Prioridades comuns são required, standard, optional,
extra, etc.
Os campos Section e Priority têm geralmente um conjunto definido de
valores aceites baseados na política específica da distribuição.
- Build-Depends: package-list
-
Uma lista de pacotes que precisam de estar instalados e configurados para
ser possível compilar a partir do pacote fonte. Estas dependências precisam
de estar satisfeitas quando se compila pacotes binários dependentes ou
independentes da arquitectura e pacotes fonte. Incluir uma dependência neste
campo não tem o mesmo efeito exacto que a incluir em ambos
Build-Depends-Arch e Build-Depends-Indep, porque a dependência também
precisa de satisfeita quando se compila o pacote fonte.
- Build-Depends-Arch: package-list
-
O mesmo que Build-Depends, mas são apenas necessárias quando se compila
os pacotes dependentes da arquitectura. Os Build-Depends são também
instalados neste caso. Este campo é suportado desde dpkg 1.16.4; de modo a
compilar com versões antigas do dpkg, deve ser usado Build-Depends em vez
disto.
- Build-Depends-Indep: package-list
-
O mesmo que Build-Depends, mas são apenas necessárias quando se compila
os pacotes independentes da arquitectura. Os Build-Depends são também
instalados neste caso.
- Build-Conflicts: package-list
-
Uma lista de pacotes que não devem estar instalados quando o pacote é
compilado, por exemplo porque interferem com o sistema de compilação
usado. Incluir uma dependência nesta lista tem o mesmo efeito que a incluir
em ambos Build-Conflicts-Arch e Build-Conflicts-Indep, com o efeito
adicional de ser usada para compilações de apenas-fonte.
- Build-Conflicts-Arch: package-list
-
O mesmo que Build-Conflicts, mas apenas quando se compila os pacotes
dependentes da arquitectura. Este campo é suportado desde dpkg 1.16.4; de
modo a compilar com versões antigas do dpkg, deve ser usado
Build-Conflicts em vez disto.
- Build-Conflicts-Indep: package-list
-
O mesmo que Build-Conflicts. mas apenas quando se compila os pacotes
independentes da arquitectura.
A sintaxe dos campos Build-Depends, Build-Depends-Arch e
Build-Depends-Indep é uma lista de grupos de pacotes alternativos. Cada
grupo é uma lista de pacotes separados por símbolos de barra vertica (ou
"pipe"), '|'. OS grupos estão separados por vírgulas ',', e podem
terminar com uma vírgula final que será eliminada ao gerar os campos para
deb-control(5) (desde dpkg 1.10.14). As virgulas devem ler-se como "E", e
os pipes como "OU", com os pipes a vincular com mais firmeza, Cada nome de
pacote é seguido opcionalmente por um qualificador de arquitectura anexado
após dois pontos ':', opcionalmente seguido por uma especificação de
número de versão em parêntesis '(' e ')', uma especificação de
arquitectura em parêntesis rectos '[' e ']', e uma fórmula de
restrição consistindo de uma ou mais listas de nomes de perfis em colchetes
angulares '<' e '>'.
A sintaxe dos campos Build-Conflicts, Build-Conflicts-Arch e
Build-Conflicts-Indep é uma lista de nomes de pacotes separados por
vírgulas, onde a vírgula é lida com um ``E'', e onde a lista por terminar com
uma vírgula final que será eliminada ao se gerar os campos para
deb-control(5) (desde dpkg 1.10.14). Especificar pacotes alternativos
usando um "pipe" não é suportado. Cada nome de pacote é opcionalmente
seguido de uma especificação de número de versão em parêntesis, uma
especificação de arquitectura em parêntesis rectos, e uma fórmula de
restrição consistindo de um ou mais listas de nomes de perfis em colchetes
angulares.
Um nome qualificador de arquitectura pode ser um nome de arquitectura real
Debian (desde dpkg 1.16.5), any (desde dpkg 1.16.2) ou native (desde
dpkg 1.16.5). Se omitido, a predefinição para campos Build-Depends é a
arquitectura da máquina actual, a predefinição para campos
Build-Conflicts é any. Um nome de arquitectura real Debian irá
corresponder exactamente essa arquitectura para esse nome de pacote, any
irá corresponder a qualquer arquitectura para esse nome de pacote se o
pacote estiver marcado com Multi-Arch: allowed, e native irá
corresponder à arquitectura de compilação actual se o pacote não estiver
marcado com Multi-Arch: foreign.
Um número de versão pode começar com um '>>', nesse caso qualquer
versão posterior irá corresponder, ie pode especificar ou omitir a revisão
de empacotamento Debian (separada por um hífen). Relacionamentos de versão
aceites são '>>' para maior que, '<<' para menor que,
'>=' para maior ou igual a, '<=' para menor ou igual a, e
'=' para igual a.
Uma especificação de arquitectura consiste em um ou mais nomes de
arquitectura, separados por espaços em branco. Pode ser adicionado no inicio
de cada nome um ponto de exclamação, o que significa ``NÃO''.
Uma fórmula de restrição consiste em uma ou mais listas de restrições,
separadas por espaços em branco. Cada lista de restrição fica dentro de
colchetes angulares, os itens na lista de restrição são nomes de perfis de
compilação, separados por espaços em branco e pode ser prefixados com um
ponto de exclamação, que significa "NÃO". Uma fórmula de restrição
representa uma expressão de forma normal disjuntiva.
Note que as dependências de pacotes no conjunto build-essential podem ser
omitidas e que declarar conflitos de compilação contra elas é
impossível. Uma lista desses pacotes está no pacote build-essential.
CAMPOS DE BINÁRIOS
Note que os campos
Priority,
Section e
Homepage podem também ficar
num parágrafo binário para sobrepor o valor global do pacote fonte.
- Package: binary-package-name (necessário)
-
Este campo é usado para dar nome ao nome do pacote binário. Aplicam-se as
mesmas restrições como para um nome de pacote fonte.
- Package-Type: deb|udeb|type
-
Este campo define o tipo de pacote. udeb é para pacotes de tamanho
reduzido usados pelo instalador de debian. deb é o valor predefinido, é
assumido se o campo estiver ausente. Mais tipos podem ser adicionados no
futuro.
- Architecture: arch|all|any (necessário)
-
A arquitectura especifica em que tipo de hardware este pacote corre. Para os
pacotes que correm em toras as arquitecturas, use o valor any. Para
pacotes que são independentes da arquitectura, tais como scripts de shell e
Perl ou documentação, use o valor all. Para restringir os pacotes a certo
conjunto de arquitecturas, especifique os nomes das arquitecturas, separadas
por um espaço. É também possível colocar wildcards de arquitecturas nessa
lista (veja dpkg-architecture(1) para mais informação sobre isto).
- Build-Profiles: restriction-formula
-
Este campo especifica as condições para quais este pacote compila ou não
compila. Para expressar essas condições, é usada a mesma sintaxe de fórmula
de restrição que se usa no campo Build-Depends.
Se um parágrafo de pacote binário não conter este campo, então significa
implicitamente que compila com todos os perfis de compilação (incluindo
nenhum deles).
Por outras palavras,se um parágrafo de pacote binário estiver anotado com um
campo Build-Profiles não vazio, então este pacote binário é gerado se e
apenas se a condição expressa pela expressão de forma normal conjuntiva ser
avaliada como verdadeira.
- Protected: Byes|no
-
- Essential: yes|no
-
- Build-Essential: yes|no
-
- Multi-Arch: same|foreign|allowed|no
-
- Tag: tag-list
-
- Description: short-description (recomendado)
-
Estes campos estão descritos no manual do deb-control(5), pois eles são
literalmente copiados para o ficheiro de controle do pacote binário.
- Depends: package-list
-
- Pre-Depends: package-list
-
- Recommends: package-list
-
- Suggests: package-list
-
- Breaks: package-list
-
- Enhances: package-list
-
- Replaces: package-list
-
- Conflicts: package-list
-
- Provides: package-list
-
- Built-Using: package-list
-
Estes campos declaram relacionamentos entre pacotes. Eles são discutidos no
manual deb-control(5). Quando estes campos são encontrados em
debian/control eles podem também terminar com uma vírgula final (desde
dpkg 1.10.14), têm especificações de arquitectura, e fórmulas de restrição
que serão todas reduzidas quando se gera os campos para deb-control(5).
- Subarchitecture: value
-
- Kernel-Version: value
-
- Installer-Menu-Item: value
-
Estes campos são usados pelo instalador de debian em udebs e geralmente
não são necessários Veja /usr/share/doc/debian-installer/devel/modules.txt
do pacote debian-installer para mais detalhes acerca deles.
CAMPOS DEFINIDOS PELO UTILIZADOR
É permitido adicionar campos adicionais definidos pelo utilizador. As
ferramentas irão ignorar estes campos. -Se deseja que os campos sejam
copiados os ficheiros resultantes, tal como um pacote binário, você precisa
de usar um esquema de nomeação personalizado: os campos devem começar com um
X, seguido de zero ou mais das letras
SBC e um hífen.
- S
-
O campo irá aparecer no ficheiro de controle do pacote fonte, veja
dsc(5).
- B
-
O campo irá aparecer no ficheiro de controle do pacote binário, veja
deb-control(5).
- C
-
O campo irá aparecer no ficheiro de controle de envio (.changes), veja
deb-changes(5).
Note que os prefixos X[SBC]- são cortados quando so campos são
copiados para os ficheiros resultantes. Um campo XC-Approved-By irá
aparecer como Approved-By no ficheiro changes e não irá aparecer nos
ficheiros de controle de pacote binário ou fonte.
Tenha em conta que estes campos definidos pelo utilizador irão usar o espaço
de nomes global, o que poderá em algum ponto no futuro colidir com campos
oficialmente reconhecidos. Para evitar tal potencial situação, você pode
prefixar esse campos com Private-, tal como XB-Private-New-Field.
EXEMPLO
# 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: https://wiki.debian.org/Teams/Dpkg
Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git
Vcs-Git: https://git.dpkg.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.
VEJA TAMBÉM
deb822(5),
deb-control(5),
deb-version(7),
dpkg-source(1)
TRADUÇÃO
Américo Monteiro
Se encontrar algum erro na tradução deste documento, por favor comunique para
Américo Monteiro <a_monteiro@gmx.com>.