Provided by: dpkg-dev_1.19.0.5ubuntu2.4_all 
NAAM
deb-src-control - Indeling van het hoofdcontrolebestand van Debian-broncodepakketten
OVERZICHT
debian/control
BESCHRIJVING
Elk Debian broncodepakket bevat het hoofdcontrolebestand «control», dat tenminste uit twee
paragrafen bestaat, gescheiden door een witregel. De eerste paragraaf geeft alle
informatie weer over het broncodepakket in het algemeen, terwijl elke daaropvolgende
paragraaf exact één binair pakket beschrijft. Elke paragraaf bestaat minstens uit één
veld. Een veld begint met de veldnaam, zoals Package of Section (niet
hoofdlettergevoelig), gevolgd door een dubbele punt, het tekstgedeelte van het veld en een
regeleinde. Velden mogen ook uit meerdere regels bestaan, maar iedere bijkomende regel
zonder veldnaam moet minstens met één spatie beginnen. Gereedschap voegt de inhoud van
velden die uit meerdere regels bestaan, meestal samen tot één regel (behalve in het geval
van het veld Description; zie hierna). Om lege regels toe te voegen in een veld dat uit
meerdere regels bestaat, moet u na de spatie een punt toevoegen. Regels die met een ‘#’
beginnen worden als commentaar behandeld.
VELDEN BRONCODEPAKKET
Source: broncodepakket-naam (verplicht)
De waarde van dit veld is de naam van het broncodepakket en moet overeenkomen met
de naam van het broncodepakket in het bestand debian/changelog. Een pakketnaam mag
enkel bestaan uit kleine letters (a-z), cijfers (0-9), plussen (+) en minnen (-) en
punten (.). Pakketnamen moeten minstens twee tekens lang zijn en moeten met een
alfanumeriek teken beginnen.
Maintainer: volledige-naam-en-e-mail (aanbevolen)
Moet volgens de indeling «Joe Bloggs <jbloggs@foo.com>» opgemaakt zijn en verwijzen
naar de persoon die momenteel het pakket onderhoudt, in tegenstelling tot de auteur
van de software of de originele verpakker ervan.
Uploaders: volledige-naam-en-e-mailadres
Somt al de namen en de e-mailadressen op van de personen die het pakket mee
onderhouden volgens dezelfde indeling als van het veld Maintainer. Meerdere
mede-onderhouders moeten onderling door een komma gescheiden worden.
Standards-Version: versietekenreeks
Dit documenteert de meest recente versie van de normen die vastgelegd werden in de
richtlijnen van de distributie en waaraan dit pakket voldoet.
Description short-description
uitgebreide-beschrijving
The format for the source package description is a short brief summary on the first
line (after the Description field). The following lines should be used as a
longer, more detailed description. Each line of the long description must be
preceded by a space, and blank lines in the long description must contain a single
‘.’ following the preceding space.
Homepage: URL
De URL van de homepage van het toeleverend project (upstream).
Bugs: URL
De URL van het bugopvolgingssysteem voor dit pakket. De momenteel gebruikte
indeling is bts-type://bts-adres, zoals debbugs://bugs.debian.org. Meestal is dit
veld niet nodig.
Rules-Requires-Root: no|binary-targets|impl-keywords
This field is used to indicate whether the debian/rules file requires (fake)root
privileges to run some of its targets, and if so when.
no The binary targets will not require (fake)root at all.
binary-targets
The binary targets must always be run under (fake)root. This value is the
default when the field is omitted; adding the field with an explicit
binary-targets while not strictly needed, marks it as having been analyzed
for this requirement.
impl-keywords
This is a space-separated list of keywords which define when (fake)root is
required.
Keywords consist of namespace/cases. The namespace part cannot contain "/"
or whitespace. The cases part cannot contain whitespace. Furthermore, both
parts must consist entirely of printable ASCII characters.
Each tool/package will define a namespace named after itself and provide a
number of cases where (fake)root is required. (See "Implementation provided
keywords" in rootless-builds.txt).
When the field is set to one of the impl-keywords, the builder will expose
an interface that is used to run a command under (fake)root. (See "Gain
Root API" in rootless-builds.txt.)
Vcs-Arch: URL
Vcs-Bzr: URL
Vcs-Cvs: URL
Vcs-Darcs: URL
Vcs-Git: URL
Vcs-Hg: URL
Vcs-Mtn: URL
Vcs-Svn: URL
De URL van de opslagruimte van het versiecontrolesysteem dat gebruikt wordt bij het
onderhouden van dit pakket. Momenteel worden ondersteund: Arch, Bzr (Bazaar), Cvs,
Darcs, Git, Hg (Mercurial), Mtn (Monotone) en Svn (Subversion). Meestal verwijst
dit veld naar de laatste versie van het pakket, zoals de hoofdtak (main branch) of
de stam (trunk)
Vcs-Browser: URL
De URL van een webinterface om door de opslagruimte van het versiecontrolesysteem
te bladeren.
Origin: naam
De naam van de distributie waaruit dit pakket afkomstig is. Meestal is dit veld
niet nodig.
Section: sectie
Dit is een veld van algemene aard dat het pakket in een categorie onderbrengt op
basis van de software die het installeert. Enkele gebruikelijke secties zijn utils,
net, mail, text, x11, enz.
Priority: prioriteit
Duidt het belang van dit pakket aan in verhouding tot het gehele systeem.
Gebruikelijke prioriteiten zijn required, standard, optional, extra, enz.
De velden Section en Priority hebben gewoonlijk een welbepaalde set mogelijke
waarden, afhankelijk van de richtlijnen van de distributie.
Build-Depends: pakketlijst
Een lijst van pakketten die geïnstalleerd en geconfigureerd moeten zijn om het
pakket uit de broncode te kunnen bouwen. Aan deze vereisten moet voldaan zijn bij
het bouwen van binaire architectuurafhankelijke of architectuuronafhankelijke
pakketten en broncodepakketten. Een vereiste vermelden in dit veld heeft niet exact
hetzelfde effect als ze zowel in Build-Depends-Arch als in Build-Depends-Indep
vermelden, aangezien ook voldaan moet zijn aan de vereiste voor het bouwen van het
broncodepakket.
Build-Depends-Arch: pakketlijst
Hetzelfde als Build-Depends, maar ze zijn enkel nodig bij het bouwen van de
architectuurafhankelijke pakketten. In dit geval worden ook de pakketten uit
Build-Depends geïnstalleerd. Dit veld wordt ondersteund sinds dpkg 1.16.4; om met
oudere versies van dpkg pakketten te bouwen moet in plaats daarvan Build-Depends
gebruikt worden.
Build-Depends-Indep: pakketlijst
Hetzelfde als Build-Depends, maar ze zijn enkel nodig bij het bouwen van de
architectuuronafhankelijke pakketten. In dit geval worden ook de pakketten uit
Build-Depends geïnstalleerd.
Build-Conflicts: pakketlijst
Een lijst van pakketten die niet geïnstalleerd mogen zijn bij het bouwen van het
pakket, bijvoorbeeld omdat ze interfereren met het gebruikte bouwsysteem. Een
afhankelijkheidsrelatie opnemen in deze lijst heeft hetzelfde effect als ze zowel
in Build-Conflicts-Arch als in Build-Conflicts-Indep opnemen, met het bijkomende
effect dat ze ook gebruikt wordt als enkel het broncodepakket gebouwd wordt.
Build-Conflicts-Arch: pakketlijst
Hetzelfde als Build-Conflicts, maar enkel bij het bouwen van de
architectuurafhankelijke pakketten. Dit veld wordt ondersteund sinds dpkg 1.16.4;
om met oudere versies van dpkg pakketten te bouwen moet in plaats daarvan
Build-Conflicts gebruikt worden.
Build-Conflicts-Indep: pakketlijst
Hetzelfde als Build-Conflicts, maar enkel bij het bouwen van de
architectuuronafhankelijke pakketten.
The syntax of the Build-Depends, Build-Depends-Arch and Build-Depends-Indep fields is a
list of groups of alternative packages. Each group is a list of packages separated by
vertical bar (or “pipe”) symbols, ‘|’. The groups are separated by commas ‘,’, and can
end with a trailing comma that will be eliminated when generating the fields for
deb-control(5) (since dpkg 1.10.14). Commas are to be read as “AND”, and pipes as “OR”,
with pipes binding more tightly. Each package name is optionally followed by an
architecture qualifier appended after a colon ‘:’, optionally followed by a version number
specification in parentheses ‘(’ and ‘)’, an architecture specification in square brackets
‘[’ and ‘]’, and a restriction formula consisting of one or more lists of profile names in
angle brackets ‘<’ and ‘>’.
The syntax of the Build-Conflicts, Build-Conflicts-Arch and Build-Conflicts-Indep fields
is a list of comma-separated package names, where the comma is read as an “AND”, and where
the list can end with a trailing comma that will be eliminated when generating the fields
for deb-control(5) (since dpkg 1.10.14). Specifying alternative packages using a “pipe”
is not supported. Each package name is optionally followed by a version number
specification in parentheses, an architecture specification in square brackets, and a
restriction formula consisting of one or more lists of profile names in angle brackets.
De naam van een architectuurkwalificatie kan een echte Debian-architectuurnaam zijn (sinds
dpkg 1.16.5), any (sinds dpkg 1.16.2) of native (since dpkg 1.16.5). Indien ze weggelaten
is, is de standaard voor het veld Build-Depends de architectuur van de huidige computer en
voor het veld Build-Conflicts is dat any. Een echte Debian-architectuurnaam komt exact
overeen met die architectuur voor die pakketnaam; any komt overeen met om het even welke
architectuur voor die pakketnaam als het pakket gemarkeerd werd als Multi-Arch: allowed;
native komt overeen met de huidige bouwarchitectuur indien het pakket niet gemarkeerd werd
als Multi-Arch: foreign.
Een versienummer kan beginnen met een ‘>>’. In dat geval levert dit met alle latere
versies een overeenkomst op. Een versienummer kan al dan niet ook een Debian-pakketrevisie
bevatten (met een koppelteken tussen versienummer en Debian-pakketrevisie). Toegestane
versierelaties zijn ‘>>’ voor hoger dan, ‘<<’ voor lager dan, ‘>=’ voor hoger of gelijk
aan, ‘<=’ voor lager of gelijk aan en ‘=’ voor gelijk aan.
Een architectuuraanduiding bestaat uit één of meer architectuurnamen, onderling gescheiden
door witruimte. Een uitroepteken mag elk van de namen voorafgaan, hetgeen de betekenis
heeft van “NOT” (niet).
Een restrictieve formule bestaat uit één of meer restrictieve lijsten, onderling
gescheiden door witruimte. Elke restrictieve lijst staat tussen accolades. De items in de
restrictieve lijst zijn bouwprofielnamen, onderling gescheiden door witruimte, en kunnen
voorafgegaan worden door een uitroepteken, hetgeen de betekenis heeft van “NOT” (niet).
Een restrictieve formule heeft de verschijningsvorm van een expressie in disjunctieve
normaalvorm.
Merk op dat de vermelding dat pakketten vereist worden die behoren tot de categorie
build-essential, weggelaten kan worden en dat het onmogelijk is om tegenover dergelijke
pakketten een bouwtegenstrijdigheid te formuleren. Een lijst van deze pakketten is te
vinden in het pakket build-essential.
VELDEN BINAIR PAKKET
Merk op dat de velden Priority, Section en Homepage ook in een paragraaf van het binaire
pakket kunnen voorkomen ter vervanging van de globale waarde uit het broncodepakket.
Package: naam-binair-pakket (verplicht)
Dit veld wordt gebruikt om de naam van het binaire pakket te vermelden. Dezelfde
restricties gelden als voor de naam van een broncodepakket.
Package-Type: deb|udeb|type
Dit veld definieert het pakkettype. udeb is voor pakketten waarvan de omvang aan
beperkingen onderworpen is en die door het installatieprogramma van Debian gebruikt
worden. deb is de standaardwaarde, die verondersteld wordt als het veld ontbreekt.
In de toekomst kunnen nog andere types toegevoegd worden.
Architecture: arch|all|any (verplicht)
De architectuur geeft aan op welk type hardware dit pakket werkt. Gebruik de waarde
any voor pakketten die op alle architecturen werken. Voor pakketten die
architectuuronafhankelijk zijn, zoals shell- en Perl-scripts of documentatie, moet
u de waarde all gebruiken. Om pakketten tot een bepaalde set van architecturen te
beperken, moet u de namen van de architecturen opgeven, onderling gescheiden door
een spatie. Het is ook mogelijk om architectuur-jokers te plaatsen in de lijst (zie
dpkg-architecture(1) voor bijkomende informatie daarover).
Build-Profiles: restrictie-formule
Dit veld geeft de condities aan waaronder dit binaire pakket al dan niet te bouwen
is. Om deze conditie uit te drukken wordt voor de restrictieformule dezelfde
syntaxis gebruikt als die van het veld Build-Depends.
Indien de paragraaf over een binair pakket dit veld niet bevat, dan betekent dit
impliciet dat het te bouwen is met alle bouwprofielen (met inbegrip van helemaal
geen).
Met andere woorden, indien aan de paragraaf betreffende een binair pakket een
niet-leeg Build-Profiles-veld toegevoegd is, dan wordt dat binair pakket
gegenereerd indien en enkel indien de conditie die uitgedrukt wordt door de
expressie in conjunctieve normaalvorm als waar geëvalueerd wordt.
Essential: yes|no
Build-Essential: yes|no
Multi-Arch: same|foreign|allowed|no
Tag: lijst-van-markeringen
Description: korte-beschrijving (aanbevolen)
Deze velden worden beschreven in de man-pagina deb-control(5), vermits zij
letterlijk naar het controlebestand van het binaire pakket gekopieerd worden.
Depends: pakketlijst
Pre-Depends: pakketlijst
Recommends: pakketlijst
Suggests: pakketlijst
Breaks: pakketlijst
Enhances: pakketlijst
Replaces: pakketlijst
Conflicts: pakketlijst
Provides: pakketlijst
Built-Using: pakketlijst
These fields declare relationships between packages. They are discussed in the
deb-control(5) manpage. When these fields are found in debian/control they can
also end with a trailing comma (since dpkg 1.10.14), have architecture
specifications and restriction formulas which will all get reduced when generating
the fields for deb-control(5).
Subarchitecture: waarde
Kernel-Version: waarde
Installer-Menu-Item: waarde
These fields are used by the debian-installer in udebs and are usually not needed.
See /usr/share/doc/debian-installer/devel/modules.txt from the debian-installer
package for more details about them.
DOOR DE GEBRUIKER GEDEFINIEERDE VELDEN
It is allowed to add additional user-defined fields to the control file. The tools will
ignore these fields. If you want the fields to be copied over to the output files, such as
the binary packages, you need to use a custom naming scheme: the fields should start with
an X, followed by zero or more of the letters SBC and a hyphen.
S Het veld zal voorkomen in het control-bestand van het broncodepakket, zie dsc(5).
B Het veld zal voorkomen in het control-bestand van het binair pakket, zie
deb-control(5).
C Het veld zal voorkomen in het controlebestand (.changes) van de upload, zie
deb-changes(5).
Note that the X[SBC]- prefixes are stripped when the fields are copied over to the output
files. A field XC-Approved-By will appear as Approved-By in the changes file and will not
appear in the binary or source package control files.
Houd er rekening mee dat deze door de gebruiker gedefinieerde velden gebruik maken van de
globale naamruimte, waardoor ze op een gegeven ogenblik in de toekomst in botsing zouden
kunnen komen met officieel erkende velden. Om deze mogelijke situatie te vermijden kunt u
die velden laten voorafgaan door Private-, zoals XB-Private-Nieuw-Veld.
VOORBEELD
# Commentaar
Source: dpkg
Section: admin
Priority: required
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
# dit veld wordt gekopieerd naar het binaire en het broncodepakket
XBS-Upstream-Release-Status: stable
Homepage: https://wiki.debian.org/Teams/Dpkg
Vcs-Browser: https://anonscm.debian.org/cgit/dpkg/dpkg.git
Vcs-Git: https://anonscm.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
# dit is een aangepast veld in het binaire pakket
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: Gereedschap voor pakketontwikkeling in Debian
Dit pakket levert de ontwikkelingsgereedschappen (met inbegrip
van dpkg-source) die nodig zijn om Debian broncodepakketten
uit te pakken, te bouwen en te uploaden.
.
De meeste Debian broncodepakketten zullen bijkomend gereedschap
nodig hebben om gebouwd te kunnen worden; de meeste pakketten hebben
bijvoorbeeld make nodig en de C-compiler gcc.
ZIE OOK
deb-control(5), deb-version(7), dpkg-source(1)