Scroll to navigation

deb-control(5) dpkg suite deb-control(5)

NOME

deb-control - formato Debian de ficheiro de controle de pacote binário

RESUMO

DEBIAN/control

DESCRIÇÃO

Cada pacote binário Debian contem um ficheiro control no seu membro control, e o seu formato deb822(5) é um subconjunto do ficheiro modelo de controle de fonte debian/control em pacotes fonte Debian, veja deb-src-control(5).

Este ficheiro contém um número de campos. Cada campo começa com uma etiqueta, tal como Package ou Version (insensitivo a maiúsculas/minúsculas) seguido por dois pontos (:), e o corpo do campo (sensível a maiúsculas/minúsculas a menos que declarado o contrário). Os campos são delimitados apenas pelas etiquetas de campo, por outras palavras, o texto do campo pode ter múltiplas linhas de comprimento, mas as ferramentas de instalação irão geralmente juntar as linhas quando processam o corpo do campo (excepto no caso do campo Description, veja em baixo).

CAMPOS

O valor deste campo determina o nome do pacote, e é usado para gerar nomes de ficheiros pela maioria das ferramentas de instalação.
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.
Tipicamente, isto é o número de versão do pacote original seja em que formato o autor do programa usa. Pode também incluir um número de revisão Debian (para pacotes não-nativos). O formato exacto e algoritmo de ordenação estão descritos em deb-version(7).
Deverá estar no formato "Joe Bloggs <jbloggs@foo.com>", e é tipicamente a pessoa que criou o pacote, e não o autor do software que foi empacotado.
 long-description
O formato da descrição do pacote é um sumário breve e curto an 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.
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.
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.

O tamanho total aproximado dos ficheiros instalados pelo pacote, em unidades KiB. O algoritmo para computar o tamanho está descrito em deb-substvars(5).
Este campo normalmente não é necessário quando a resposta é yes. Ele indica um pacote que é necessário principalmente para o arranque correcto do sistema ou usado para meta-pacotes personalizados locais-do-sistema. O dpkg(1) ou qualquer outra ferramenta de instalação não irá permitir que um pacote Protected seja removido (pelo menos não sem usar uma das opções de forçar).

Suportado desde dpkg 1.20.1.

Este campo normalmente não é necessário quando a resposta é sim. Ele indica um pacote que é necessário para o sistema de empacotamento, para a operação correcta do sistema no geral ou durante o arranque (apesar do último dever ser convertido para o campo Protected em vez deste). O dpkg(1) ou qualquer outra ferramenta de instalação não irá permitir que um pacote <Essential> seja removido (pelo menos não sem usar uma das opções de forçar).
Este campo geralmente não é necessário quando a resposta é sim, e é injetado de modo comum pelo software do arquivo. Denota um pacote que é requerido quando se compila outros pacotes.
A arquitectura especifica para que tipo de hardware este pacote foi compilado. Arquitecturas comuns são amd64, armel, i386, powerpc, etc. Note que o valor all é destinada a pacotes que são independentes da arquitectura. Alguns exemplos disto são scripts de shell e Perl, e documentação.
O nome da distribuição de onde este pacote originou.
O url do sistema de acompanhamento de bugs deste pacote. O formato actualmente usado é tipo-bts://endereço-bts, como debbugs://bugs.debian.org.
O url da página inicial do projecto do autor.
Lista de etiquetas que descrevem as qualidades do pacote. A descrição e a lista de etiquetas suportadas pode ser encontrada no pacote debtags.
Este campo é usado para indicar como este pacote deve comportar-se em instalações de multi-arquitectura.
Este valor é a predefinição quando o campo é omitido, e neste caso adicionar o campo com um valor no explícito geralmente não é necessário.
Este pacote é co-instalável com ele próprio, mas não pode ser usado para satisfazer a dependência de qualquer pacote de uma arquitectura diferente de ele próprio.
Este pacote não é co-instalável com ele próprio, mas deve ser permitido satisfazer uma dependência non-arch-qualified de um pacote de uma arquitectura diferente dele próprio (se uma dependência tiver um arch-qualifier explícito então o valor foreign é ignorado).
Isto permite a dependências-reversas indicarem no seu campo Depends que elas aceitam este pacote de outra arquitectura ao qualificar o nome do pacote com :any, mas de outro modo não tem efeito.
O nome do pacote fonte de onde este pacote binário veio, se for diferente do nome do próprio pacote. Se a versão fonte diferir da versão binária, então o source-name será seguido por um source-version em parênteses. Isto pode acontecer por exemplo, num envio de não-maintainer apenas-binário, ou quando se define uma versão binária diferente via «dpkg-gencontrol -v».
Estes campos são usados pelo instalador de debian e geralmente não são necessários. Para mais detalhes acerca deles, veja <https://salsa.debian.org/installer-team/debian-installer/-/raw/master/doc/devel/modules.txt>.
Lista de pacotes que ao requeridos para este pacotes poder disponibilizar uma não-trivial quantidade de funcionalidades. O software de manutenção de pacotes não irá permitir que o pacote seja instalado se os pacotes listados no seu campo Depends não estiverem instalados (pelo menos não sem sem serem usadas opções de forçar). Numa instalação, os scripts postinst dos pacotes listados nos campos Depends são corridos antes daqueles do pacote que depende deles. Em oposto, numa remoção, o script prerm de um pacote é corrido antes daqueles dos pacotes listados no seu campo Depends.
Lista de pacotes que têm de ser instalados e configurados antes de este poder ser instalado. Isto é usado geralmente quando este pacote requer outro programa para correr o seu script preinst.
Lista pacotes que seriam encontrados juntamente com este em todas as instalações menos nas forma do normal. O software de manutenção de pacotes irá avisar o utilizador se ele instalar um pacote sem aqueles listados no campo Recommends.
Lista pacotes que estão relacionados com este e podem talvez aumentar a sua utilidade, mas é perfeitamente razoável instalar este pacote sem eles.

A sintaxe dos campos Depends, Pre-Depends, Recommends e Suggests é uma lista de grupos de pacotes alternativos. Cada grupo é uma lista de pacotes separados por símbolos de barras verticais (ou “pipe”) ‘|’. Os grupos são separados por vírgulas, As vírgulas devem ser lidas como "E", e os pipes como "OU", com os pipes a vincular com mais firmeza. Cada nome de pacote é opcionalmente seguido 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.

Um nome qualificador de arquitectura pode ser um nome de arquitectura Debian real (desde dpkg 1.16.5) ou any (desde dpkg 1.16.2). Se omitido, a predefinição é a arquitectura do pacote binário actual. Um nome de arquitectura Debian real irá corresponder exactamente à arquitectura para o nome do pacote. any irá corresponder a qualquer arquitectura para esse nome de pacote. se o pacote foi marcado como Multi-Arch: allowed.

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.

Lista os pacotes que este quebra, por exemplo ao expor bugs quando os pacotes nomeados precisam deste. O software de manutenção de pacotes não irá permitir que pacotes quebrados sejam configurados; geralmente a resolução é actualizar os pacotes nomeados no campo Breaks.
Lista os pacotes que entram em conflito com este, por exemplo por conter ficheiros com os mesmos nomes. O software de manutenção de pacotes não irá permitir que pacotes em conflito sejam instalados ao mesmo tempo. Dois pacotes em conflito deverão ambos incluir uma linha Conflicts mencionando o outro.
Lista os pacotes que este substitui. Isto é usado para permitir que este pacote sobrescreva os ficheiros de outro pacote e é geralmente usado com o campo Conflicts para forçar a remoção do outro pacote. caso este tenha os mesmos ficheiros que o pacote em conflito.

A sintaxe de Breaks, Conflicts e Replaces é uma lista de nomes de pacotes, separados por vírgulas (e opcionalmente por espaços em branco). Nos campos Breaks e Conflicts, a vírgula deve ler-se como "OU". Um qualificador opcional de arquitectura pode também ser anexado ao nome do pacote com a mesma sintaxe de em cima, mas a predefinição é any em vez da arquitectura de pacote binário. Pode também ser fornecida uma versão opcional com a mesma sintaxe como em cima para os campos Breaks, Conflicts e Replaces.

Isto é uma lista de pacotes que este melhora. É semelhante a Suggests mas na direcção oposta.
Isto é uma lista de pacotes virtuais que este fornece. Geralmente sito é usado no caso de vários pacotes todos fornecerem o mesmo serviço. Por exemplo, sendmail e exim podem servir como servidor de mail, assim eles fornecem um pacote comum (“mail-transport-agent”) sobre o qual outros pacotes podem depender. Isto vai permitir ao sendmail ou ao exim servir como opção válida para satisfazer a dependência. Isto previne que os pacotes que dependem de um servidor de mail tenham que saber os nomes de pacotes de todos eles, e usar ‘|’ para separar a lista.

A sintaxe de Provides é uma lista de nomes de pacotes, separados por vírgulas (e opcionalmente por espaços em branco). Um qualificador opcional de arquitectura pode também ser anexado ao nome do pacote com a mesma sintaxe de em cima. Se omitido, a predefinição é a arquitectura do pacote binário actual. Uma versão exacta (igual a) opcional pode também ser dada com a mesma sintaxe de em cima (honrado desde dpkg 1.17.11).

Este campo de dependência lista pacotes fonte extra que foram usados durante a compilação deste pacote binário, com o objectivo de respeitar licenças. Isto é uma indicação para o software de manutenção do arquivo que estes pacotes fonte extra têm de ser mantidos enquanto este pacote biblioteca for mantido. Este campo tem de ser uma lista de nomes de pacotes fonte separados por vírgulas com relacionamentos de versão estritos ‘=’ fechados dentro de parênteses. Note que é provável que o software de manutenção do arquivo se recuse a aceitar um envio que declare uma relação Built-Using que não possa ser satisfeita dentro do arquivo.
Este campo de dependência lista pacotes fonte extra que foram usados durante a compilação deste pacote binário, para objectivos de compilação estática (por exemplo vincular contra bibliotecas estáticas. compilações para linguagens centradas-na-fonte tais como Go ou Rust, utilização de bibliotecas C/C++ apenas-cabeçalho, injectar bolhas de dados em código, etc.). Isto é útil para seguir se este pacote pode precisar de ser recompilado quando os pacotes fonte listados aqui forem actualizados, por exemplo devido a actualizações de segurança. Este campo tem de ser uma lista separada por vírgulas de nomes de pacotes fonte com relacionamentos estritos de versão ‘=’ fechados dentro de parênteses.

Suportado desde dpkg 1.21.3.

Este campo era usado para especificar uma lista de perfis de compilação separados por espaços com que este pacote binário foi compilado com (desde dpkg 1.17.2 até 1.18.18). A informação antes encontrada neste campo pode agora ser encontrada no ficheiro .buildinfo, que o suplanta.
Esta campo especifica uma lista de razões separadas por espaços de porquê este pacote foi auto-gerado. OS pacotes binários marcados com este campo não irão aparecer no ficheiro de controle fonte modelo debian/control. A única razão usada actualmente é debug-symbols.
Este campo especifica uma lista de ids de compilação de ELF separados por espaços. Estes são identificadores únicos para objetos ELF semanticamente idênticos, para cada um destes dentro do pacote.

O formato ou o modo de computar cada build-id não é definido pelo desenho.

EXEMPLO

 Package: grep
 Essential: yes
 Priority: required
 Section: base
 Maintainer: Wichert Akkerman <wakkerma@debian.org>
 Architecture: sparc
 Version: 2.4-1
 Pre-Depends: libc6 (>= 2.0.105)
 Provides: rgrep
 Conflicts: rgrep
 Description: GNU grep, egrep and fgrep.
  The GNU family of grep utilities may be the "fastest grep in the west".
  GNU grep is based on a fast lazy-state deterministic matcher (about
  twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
  search for a fixed string that eliminates impossible text from being
  considered by the full regexp matcher without necessarily having to
  look at every character. The result is typically many times faster
  than Unix grep or egrep. (Regular expressions containing backreferencing
  will run more slowly, however).

BUGS

O campo Build-Ids usa um nome um pouco genérico fora do seu contexto original dentro de um objeto ELF, o que serve um objectivo muito específico e formato executável.

VEJA TAMBÉM

deb822(5), deb-src-control(5), deb(5), deb-version(7), debtags(1), dpkg(1), dpkg-deb(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>.

2024-08-01 1.22.11