deb-src-control
Section: dpkg-suite (5)
Updated: 2020-03-23
Index
Return to Main Contents
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 (a-z0-9)
in kleine letter 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: korte-beschrijving
-
uitgebreide-beschrijving
De indeling van een pakketbeschrijving bestaat uit een beknopte korte
samenvatting op de eerste regel (na de veldmarkering Description). De
daaropvolgende regels moeten gebruikt worden voor een langere, meer
gedetailleerde beschrijving. Elke regel van de uitgebreide beschrijving moet
voorafgegaan worden door een spatie, en lege regels in de uitgebreide
beschrijving moeten één enkele '.' bevatten die volgt op de eraan
voorafgaande spatie.
- 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-trefwoorden
-
Dit veld wordt gebruikt om aan te geven of het bestand debian/rules
voorrechten van (fake)root nodig heeft om sommige van zijn targets uit te
voeren, en zo ja wanneer.
-
- no
-
De binaire targets zullen (fake)root helemaal niet nodig hebben.
- binary-targets
-
De binaire targets moeten altijd onder (fake)root uitgevoerd worden. Dit is
de standaardwaarde als dit veld ontbreekt. Als dit veld toegevoegd wordt met
een expliciete binary-targets, terwijl dit strikt genomen niet nodig is,
geeft dit aan dat de noodzaak ervan onderzocht werd.
- impl-trefwoorden
-
Dit is een door witruimte gescheiden lijst van trefwoorden die omschrijven
wanneer (fake)root vereist is.
Een trefwoord bestaat uit naamruimte/gevallen. Het onderdeel
naamruimte mag geen "/" en geen witruimte bevatten. Het onderdeel
gevallen mag geen witruimte bevatten. Voorts moeten beide delen volledig
uit afdrukbare ASCII-tekens bestaan.
Elk gereedschap/pakket zal een naamruimte definiëren die vernoemd wordt naar
zichzelf en een aantal gevallen waarin (fake)root vereist is. (Zie
"Implementation provided keywords" in rootless-builds.txt).
Wanneer het veld ingesteld is op een van de impl-trefwoorden, zal het
bouwprogramma een interface ontsluiten die gebruikt wordt om een commando
onder (fake)root uit te voeren. (Zie "Gain Root API" in
rootless-builds.txt.)
- Testsuite: namenlijst
-
Testsuite-Triggers: pakketlijst
Deze velden worden beschreven in de man-pagina dsc(5), aangezien zij
gegenereerd worden op basis van informatie, afgeleid uit
debian/tests/control, of letterlijk naar het controlebestand van de
broncode gekopieerd worden.
- 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.
De syntaxis van de velden Build-Depends, Build-Depends-Arch en
Build-Depends-Indep is een lijst van groepen van alternatieve
pakketten. Elke groep is een lijst van pakketten die onderling gescheiden
worden door het symbool verticale streep (of "pijp"), '|'. De groepen
worden onderling gescheiden door komma's ',' en de lijst kan eindigen met
een afsluitende komma, die bij het genereren van de velden voor
deb-control(5) weggelaten zal worden (sinds dpkg 1.10.14). Een komma moet
geïnterpreteerd worden als een "AND" en een pijp als een "OR", waarbij
pijpen de sterkste binding hebben. Elke pakketnaam kan facultatief gevolgd
worden door een architectuurkwalificatie, die toegevoegd wordt na een
dubbele punt ':', facultatief gevolgd door de vermelding van een
versienummer tussen ronde haakjes '(' en ')', een
architectuurspecificatie tussen vierkante haakjes '[' en ']' en een
restrictieformule die bestaat uit één of meer lijsten van profielnamen
tussen punthaakjes '<' en '>'.
De syntaxis van de velden Build-Conflicts, Build-Conflicts-Arch en
Build-Conflicts-Indep is een lijst van pakketnamen die onderling
gescheiden zijn door een komma, waarbij de komma geïnterpreteerd moet worden
als een "AND" en waarbij de lijst kan eindigen met een afsluitende komma,
die bij het genereren van de velden voor deb-control(5) weggelaten zal
worden (sinds dpkg 1.10.14).. Het specificeren van alternatieve pakketten
met behulp van een "pijp" wordt niet ondersteund. Elke pakketnaam kan
facultatief gevolgd worden door de vermelding van een versienummer tussen
ronde haakjes, een architectuurspecificatie tussen vierkante haakjes en een
restrictieformule die bestaat uit één of meer lijsten van profielnamen
tussen punthaakjes.
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 restrictieformule bestaat uit één of meer restrictielijsten, onderling
gescheiden door witruimte. Elke restrictielijst staat tussen punthaakjes. De
items in de restrictielijst zijn bouwprofielnamen, onderling gescheiden door
witruimte, en kunnen voorafgegaan worden door een uitroepteken, hetgeen de
betekenis heeft van "NOT" (niet). Een restrictieformule 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
Deze velden benoemen relaties tussen pakketten. Ze worden besproken in de
man-pagina deb-control(5). Wanneer deze velden in debian/control
voorkomen, kunnen ze ook eindigen met een afsluitende komma (sinds dpkg
1.10.14), kunnen ze architectuurspecificaties bevatten en restrictieformules
bevatten, wat bij het genereren van de velden voor deb-control(5)
allemaal teruggebracht zal worden.
- Subarchitecture: waarde
-
Kernel-Version: waarde
Installer-Menu-Item: waarde
Deze velden worden door het installatieprogramma van Debian in udeb's
gebruikt en zijn meestal niet nodig. Zie voor meer details over deze velden
/usr/share/doc/debian-installer/devel/modules.txt uit het pakket
debian-installer.
DOOR DE GEBRUIKER GEDEFINIEERDE VELDEN
Het is toegelaten om aan het bestand control bijkomende door de gebruiker
gedefinieerde velden toe te voegen. De gereedschappen zullen deze velden
negeren. Indien u wilt dat de velden mee gekopieerd worden naar de
uitvoerbestanden, zoals de binaire pakketten, moet u een aangepast
naamgevingsschema hanteren: de velden moeten beginnen met een X, gevolgd
door nul of meer van de tekens SBC en een koppelteken.
- 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).
Merk op dat de voorvoegsels X[SBC]- weggelaten worden wanneer de
velden gekopieerd worden naar de uitvoerbestanden. Een veld
XC-Approved-By zal als Approved-By in het changes-bestand vermeld
staan en niet opgenomen zijn in het control-bestand van het binair en het
bronpakket.
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://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
# 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)
Index
- NAAM
-
- OVERZICHT
-
- BESCHRIJVING
-
- VELDEN BRONCODEPAKKET
-
- VELDEN BINAIR PAKKET
-
- DOOR DE GEBRUIKER GEDEFINIEERDE VELDEN
-
- VOORBEELD
-
- ZIE OOK
-
This document was created by
man2html,
using the manual pages.
Time: 00:06:19 GMT, March 31, 2021