deb-src-control(5)

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)