deb-src-control
formato Debian de ficheiro de controle modelo de pacote fonte
- Provided by: dpkg-dev (Version: 1.23.7ubuntu1)
- Source: dpkg
- Report a bug
formato Debian de ficheiro de controle modelo de pacote fonte
debian/control
Cada pacote fonte Debian contem o ficheiro modelo de controle de fonte «debian/control», e o seu formato deb822(5) é um superconjunto do ficheiro control enviado em pacotes binários Debian, veja deb-control(5).
Este ficheiro contem pelo menos 2 estrofes, separadas por uma linha vazia. A primeira estrofe é chamada a estrofe do pacote fonte e lista toda a informação acerca do pacote fonte em geral, enquanto cada uma das estrofe seguintes são chamadas estrofes de pacote binário e descrevem exactamente um pacote binário por cada estrofe. Cada estrofe consiste de pelo menos um campo. Um campo começa com um nome de campo, tal como Package ou Section (insensível a maiúsculas/minúsculas), seguido de dois pontos, o corpo do campo (sensível a maiúsculas/minúsculas a menos que declarado o contrário) e uma mudança de linha. São também permitirmos campos multi-linha, mas cada linha suplementar, sem um nome de campo, tem de começar com pelo menos um espaço em branco. O conteúdo dos campos multi-linha é geralmente juntado numa única pelas ferramentas (excepto no caso do campo Description, ver abaixo). Para inserir linhas vazias num campo de multi-linha, insira um ponto após o espaço. As linhas começadas com ‘#’ são tratadas como comentários.
Este campo é suportado desde dpkg 1.22.7.
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.)
Quando omitido, a section predefine para unknown (desde dpkg 1.22.13).
Os valores aceites são baseados na política específica da distribuição.
Quando omitido, a priority predefine para optional (desde dpkg 1.22.13).
Como aplicar estes valores depende da política específica da distribuição.
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, e 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 (< e >). 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, que é um espaço em branco dentro de colchetes angulares fechados é lida como “E”, e espaço em branco entre colchetes angulares a fechar é lido como “OU“, tal como “<foo E bar> OU <quux E baz>”.
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.
O valor especial all, por ele próprio, destina-se a pacotes que são independentes da arquitectura (tais como scripts de shell e Perl ou documentação), o valor wildcard especial any, por ele próprio, destina-se a pacotes que são dependentes da arquitectura mas correm em todas as arquitecturas (o que corresponde a todos os nomes de arquitectura específicos, excluindo all). A maioria dos pacotes vão usar ou all ou any. Para restringir os pacotes a um certo conjunto de arquitecturas, especifique um ou mais nomes de arquitecturas e/ou wildcards de arquitecturas, separados por espaços.
Um nome de arquitectura ou wildcard tem de começar com um caractere alfanumérico (“0-9a-zA-Z”), e depois seguido por caracteres alfanuméricos e traço (‘-’).
Para mais informação sobre nomes de arquitecturas e wildcards, veja dpkg-architecture(1).
Se uma estrofe 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 uma estrofe 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.
Se não existir nenhum campo na estrofe de binário ou fonte, então predefine para unknown (desde dpkg 1.22.13).
Se não existir nenhum campo na estrofe de binário ou fonte, então predefine para optional (desde dpkg 1.22.13).
É 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.
Apenas esperado na estrofe do pacote fonte.
Permitido na estrofe do pacote fonte ou qualquer estrofe de pacote binário.
Apenas esperado na estrofe do pacote fonte.
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.
# 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: 4.7.3
Build-Depends:
dpkg-build-api (= 1),
debhelper-compat (= 13),
debhelper (>= 13.10~),
pkgconf,
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:
libdpkg-perl (= ${source:Version}),
dpkg (>= 1.14.6),
binutils,
bzip2,
xz-utils,
# This is a comment in the middle of a field value.
make,
patch (>= 2.2-1),
perl-modules,
perl5,
Recommends:
build-essential,
gcc | c-compiler,
Suggests:
debian-keyring,
Conflicts:
devscripts (<< 2.10.26),
Replaces:
manpages-pl (<= 20051117-1),
Provides:
dpkg-build-api (= 0),
dpkg-build-api (= 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.
/usr/share/doc/dpkg/spec/rootless-builds.txt, deb822(5), deb-control(5), deb-version(7), dpkg-source(1)
Américo Monteiro
Se encontrar algum erro na tradução deste documento, por favor comunique para Américo Monteiro <a_monteiro@gmx.com>.