Provided by: dpkg-dev_1.19.7ubuntu3.2_all 
BEZEICHNUNG
deb-src-control - Dateiformat der Hauptsteuerdatei von Debian-Quellpaketen
ÜBERSICHT
debian/control
BESCHREIBUNG
Jedes Debian-Quellpaket enhält die Hauptsteuerdatei „control“, die mindestens zwei Absätze
enthält, die durch eine Leerzeile getrennt werden. Der erste Absatz führt alle allgemeinen
Informationen über das Quellpaket auf, während jeder folgende Absatz genau ein Binärpaket
beschreibt. Jeder Absatz besteht aus mindestens einem Feld. Ein Feld beginnt mit einem
Feldnamen, wie Package oder Section (Groß-/Kleinschreibung egal), gefolgt von einem
Doppelpunkt, dem Inhalt des Feldes und einem Zeilenumbruch. Mehrzeilige Felder sind auch
erlaubt, aber jede ergänzende Zeile ohne Feldnamen sollte mit mindestens einem Leerzeichen
beginnen. Der Inhalt des mehrzeiligen Feldes wird durch die Werkzeuge im Allgemeinen zu
einer Zeile zusammengeführt (das Feld Description ist eine Ausnahme, siehe unten). Um
Leerzeilen in ein mehrzeiliges Feld einzufügen, verwenden Sie einen Satzpunkt nach dem
Leerzeichen. Zeilen, die mit ‚#’ beginnen, werden als Kommentare betrachtet.
QUELLPAKET-FELDER
Source: Quellpaketname (verpflichtend)
Der Wert dieses Feldes ist der Name des Quellpakets und sollte mit dem Namen des
Quellpakets in der Datei debian/changelog übereinstimmen. Ein Paketname darf nur
aus Kleinbuchstaben (a-z), Ziffern (0-9), Plus- (+) und Minuszeichen (-) und
Satzpunkten (.) bestehen. Paketnamen müssen mindestens zwei Zeichen lang sein und
mit einem klein geschriebenen alphanumerischen Zeichen (a-z0-9) beginnen.
Maintainer: Vollständiger-Name-und-E-Mail (empfohlen)
Sollte in dem Format „Joe Bloggs <jbloggs@foo.com>“ sein und verweist auf die
Person, die derzeit das Paket betreut, im Gegensatz zum Autor der Software, die
paketiert wurde, oder dem ursprünglichen Paketierer.
Uploaders: Vollständiger-Name-und-E-Mail
Listet die Namen und E-Mail-Adressen der Ko-Betreuer des Pakets auf, im gleichen
Format wie das Feld Maintainer. Mehrere Ko-Betreuer sollten durch Kommata getrennt
werden.
Standards-Version: Versionszeichenkette
Dies dokumentiert die neuste Version der Standards der Distribution, an den sich
das Paket hält.
Description Kurzbeschreibung
Langbeschreibung
Das Format der Quellpaketbeschreibung ist eine kurze knappe Zusammenfassung auf der
ersten Zeile (nach dem Feld Description). Die folgenden Zeilen sollten als längere,
detailliertere Beschreibung verwendet werden. Jede Zeile der Langbeschreibung muss
von einem Leerzeichen begonnen werden, und Leerzeilen in der Langbeschreibung
müssen einen einzelnen ‚.’ hinter dem einleitenden Leerzeichen enthalten.
Homepage: URL
Die URL des Original- (Upstream-)Projekts.
Bugs: URL
Die URL der Fehlerdatenbank für dieses Paket. Das derzeit verwendete Format ist
BTS-Art://BTS-Adresse wie in debbugs://bugs.debian.org. Dieses Feld wird
normalerweise nicht benötigt.
Rules-Requires-Root: no|binary-targets|impl-keywords
Dieses Feld wird verwandt, um anzuzeigen, ob die Datei debian/rules
(fake)root-Priviliegien benötigt, um einige ihrer Ziele auszuführen, und falls ja,
wann.
no Die Binärziele werden überhaupt kein (fake)root benötigen.
binary-targets
Die Binärziele müssen immer unter (fake)root ausgeführt werden. Dieser Wert
ist die Vorgabe, wenn die Datei fehlt. Die Aufnahme dieses Feld mit einem
expliziten binary-targets ist zwar streng genommen nicht notwendig, markiert
aber, dass es darauf untersucht wurde.
Impl-Schlüsselwörter
Dies ist eine durch Leerzeichen getrennte Liste von Schlüsselwörtern, die
festlegen, wann (fake)root benötigt wird.
Schlüsselwörter bestehen aus Namensraum/Fälle. Der Teil Namensraum kann kein
»/« oder Leerraum enthalten. Der Teil Fälle kann kein Leerraum enthalten.
Desweiteren müssen beide Teile ausschließlich aus druckbaren ASCII-Zeichen
bestehen.
Jedes Werkzeug/Paket wird einen Namensraum nach sich selbst definieren und
eine Reihe von Fällen bereitstellen, in denen (fake)root benötigt wird
(siehe »Implementation provided keywords« in rootless-builds.txt).
Wenn das Feld auf eines der Impl-Schlüsselwörter gesetzt wird, wird das
Bauprogramm eine Schnittstelle bereitstellen, die zur Ausführung unter
(fake)root verwandt wird (siehe »Gain Root API« in rootless-builds.txt).
Testsuite: Namenliste
Testsuite-Triggers: Paketliste
Diese Felder sind in der Handbuchseite dsc(5) beschrieben, da sie aus
Informationen, die aus debian/tests/control abgeleitet sind, erstellt oder wörtlich
in die control-Datei der Quellen kopiert werden.
Vcs-Arch*: URL
Vcs-Bzr: URL
Vcs-Cvs: URL
Vcs-Darcs: URL
Vcs-Git: URL
Vcs-Hg: URL
Vcs-Mtn: URL
Vcs-Svn: URL
Die URL des Versionskontrollsystem-Depots, das für die Betreuung des Pakets
verwandt wird. Derzeit werden Arch, Bzr (Bazaar), Cvs, Darcs, Git, Hg (Mercurial),
Mtn (Monotone) und Svn (Subversion) unterstützt. Normalerweise zeigt dieses Feld
auf die neuste Version des Pakets, wie den Hauptzweig oder den Trunk.
Vcs-Browser: URL
Die URL der Webschnittstelle, um das Versionskontrollsystem-Depot anzuschauen.
Origin: Name
Der Name der Distribution, aus der dieses Paket ursprünglich stammt. Dieses Feld
wird normalerweise nicht benötigt.
Section: Sektion
Dies ist ein allgemeines Feld, das dem Paket eine Kategorie gibt, basierend auf der
Software, die es installiert. Einige übliche Sektionen sind utils, net, mail, text,
x11 usw.
Priority: Priorität
Setzt die Bedeutung dieses Pakets in Bezug zu dem Gesamtsystem. Übliche Prioritäten
sind required, standard, optional, extra usw.
Die Felder Section und Priority haben eine definierte Menge an Werten, abhängig von
den jeweiligen Distributionsrichtlinien.
Build-Depends: Paketliste
Eine Liste der Pakete, die installiert und konfiguriert sein müssen, um das Paket
aus den Quellen zu bauen. Diese Abhängigkeiten müssen erfüllt wein, wenn binäre
architekturabhängige und unabhängige und Quellpakete gebaut werden. Die Aufnahme
einer Abhängigkeit in diese Liste hat nicht den gleichen Effekt wie die Aufnahme in
Build-Depends-Arch und Build-Depends-Indep, da die Abhängigkeit auch beim Bau des
Quellpaketes erfüllt sein muss.
Build-Depends-Arch: Paketliste
Identisch zu Build-Depends, wird aber nur zum Bau der architekturabhängigen Pakete
benötigt. In diesem Fall sind die Build-Depends auch installiert. Dieses Feld wurde
seit Dpkg 1.16.4 unterstützt; um mit älteren Dpkg-Versionen zu bauen, sollte
stattdessen Build-Depends verwandt werden.
Build-Depends-Indep: Paketliste
Identisch zu Build-Depends, wird aber nur zum Bau der architekturunabhängigen
Pakete benötigt. In diesem Fall sind die Build-Depends auch installiert.
Build-Conflicts: Paketliste
Eine Liste von Paketen, die beim Bau des Pakets nicht installiert sein sollten,
beispielsweise da sie mit dem verwandten Bausystem in Konflikt geraten. Die
Aufnahme einer Abhängigkeit in diese Liste hat den gleichen Effekt wie die Aufnahme
in Build-Conflicts-Arch und Build-Conflicts-Indep mit dem zusätzlichen Effekt, dass
es für reine Quellen-Bauten verwandt wird.
Build-Conflicts-Arch: Paketliste
Identisch zu Build-Conflicts, aber nur beim Bau der architekturabhängigen Pakete.
Dieses Feld wird seit Dpkg 1.16.4 unterstützt; um mit älteren Dpkg-Versionen zu
bauen, sollte stattdessen Build-Conflicts verwandt werden.
Build-Conflicts-Indep: Paketliste
Identisch zu Build-Conflicts, wird aber nur zum Bau der architekturunabhängigen
Pakete benötigt.
Die Syntax der Felder Build-Depends, Build-Depends-Arch und Build-Depends-Indep ist eine
Liste von Gruppen von alternativen Paketen. Jede Gruppe ist eine Liste von durch vertikale
Striche (oder „Pipe“-Symbole) ‚|’ getrennten Paketen. Die Gruppen werden durch Kommata ‚,’
getrennt. Sie können mit einem abschließenden Komma enden, das beim Erstellen der Felder
für deb-control(5) entfernt wird (seit Dpkg 1.10.14). Kommata müssen als „UND“, vertikale
Striche als „ODER“ gelesen werden, wobei die vertikalen Striche stärker binden. Jeder
Paketname wird optional von einer Architektur-Spezifikation gefolgt, die nach einem
Doppelpunkt ‚:’ angehängt wird, optional gefolgt von einer Versionsnummer-Spezifikation in
Klammern ‚(’ und ‚)’, einer Architekturspezifikation in eckigen Klammern ‚[’ und ‚]’ und
einer Einschränkungsformel, die aus einer oder mehr Listen von Profilnamen in spitzen
Klammern ‚<’ und ‚>’ besteht.
Syntaxtisch werden die Felder Build-Conflicts, Build-Conflicts-Arch und
Build-Conflicts-Indep durch eine Komma-separierte Liste von Paketnamen dargestellt, wobei
das Komma als „UND“ verstanden wird. Die Liste kann mit einem abschließenden Komma enden,
das beim Erstellen der Felder für deb-control(5) entfernt wird (seit Dpkg 1.10.14). Die
Angabe alternativer Pakete mit dem „Pipe“-Symbol wird nicht unterstützt. Jedem Paketnamen
folgt optional eine Versionnummerangabe in Klammern, eine Architekturspezifikation in
eckigen Klammern und einer Einschränkungsformel, die aus einer oder mehr Listen von
Profilnamen in spitzen Klammern besteht.
Eine Architektur-Spezifikation kann ein echter Debian-Architekturname sein (seit Dpkg
1.16.5), any (seit Dpkg 1.16.2) oder native (seit Dpkg 1.16.5). Falls er fehlt, ist die
Vorgabe für das Feld Build-Depends die aktuelle Host-Architektur, die Vorgabe für das Feld
Build-Conflicts ist any. Jeder echte Debian-Architekturname passt genau auf diese
Architektur für diesen Paketnamen, any passt auf jede Architektur für diesen Paketnamen,
falls das Paket mit Multi-Arch: allowed markiert ist, und native passt auf die aktuelle
Bau-Architektur, falls das Paket nicht mit Multi-Arch: foreign markiert ist.
Eine Versionsnummer kann mit ‚>>’ beginnen, in diesem Falle passen alle neueren Versionen,
und kann die Debian-Paketrevision (getrennt durch einen Bindestrich) enthalten oder auch
nicht. Akzeptierte Versionsbeziehungen sind ‚>>’ für größer als, ‚<<’ für kleiner als,
‚>=’ für größer als oder identisch zu, ‚<=’ für kleiner als oder identisch zu und ‚=’ für
identisch zu.
Eine Architekturspezifikation besteht aus einer oder mehreren durch Leerraumzeichen
getrennten Architekturnamen. Jedem Namen darf ein Ausrufezeichen vorangestellt werden, das
„NICHT“ bedeutet.
Eine Einschränkungsformel besteht aus einer oder mehrerer durch Leerraum getrennten
Einschränkungslisten. Jede Einschränkungsliste wird in spitze Klammern eingeschlossen.
Einträge in den Einschränkungslisten sind Bauprofilnamen, getrennt durch Leerraum. Diesen
Listen kann ein Ausrufezeichen vorangestellt werden, das „NICHT“ bedeutet. Eine
Einschränkungsformel stellt einen Ausdruck in einer disjunkte Normalform dar.
Beachten Sie, dass die Abhängigkeiten von Paketen aus der Menge der build-essential
entfallen kann und die Angabe von Baukonflikten gegen sie nicht möglich ist. Eine Liste
dieser Pakete befindet sich im Paket build-essential.
BINÄRPAKET-FELDER
Beachten Sie, dass die Felder Priority, Section und Homepage sich auch im
Binärprogrammabsatz befinden können, um die globalen Werte des Quellpakets zu
überschreiben.
Package: Binärpaketname (verpflichtend)
Dieses Feld wird zur Angabe des Binärpaketnamens verwandt. Es gelten die gleichen
Einschränkungen wie beim Quellpaketnamen.
Package-Type: deb|udeb|type
Dieses Feld definiert die Art des Pakets. udeb ist für größenbegrenzte Pakete, wie
sie vom Debian-Installer verwandt werden. deb ist der Standardwert, er wird
angenommen, falls das Feld fehlt. Weitere Typen könnten in der Zukunft hinzugefügt
werden.
Architecture: arch|all|any (verpflichtend)
Die Architektur gibt an, auf welcher Art von Hardware dieses Paket läuft. Bei
Paketen, die auf allen Architekturen laufen, verwenden Sie den Wert any. Für
Pakete, die architekturunabhängig sind, wie Shell- und Perl-Skripte oder
Dokumentation, verwenden Sie den Wert all. Um das Paket für einen bestimmten Satz
von Architekturen zu begrenzen, geben Sie die durch Leerzeichen getrennten Namen
der Architekturen an. Es ist auch möglich, Platzhalter für Architekturen in dieser
Liste anzugeben (lesen Sie dpkg-architecture(1) für weitere Informationen dazu).
Build-Profiles: Einschränkungsformel
Dieses Feld legt die Bedingungen fest, zu denen dieses Binärpaket (nicht) baut. Um
diese Bedingung auszudrücken, wird die Einschränkungsformelsyntax aus dem Feld
Build-Depends verwandt.
Falls der Absatz eines binären Pakets dieses Feld nicht enthält, dann bedeutet dies
implizit, dass es mit allen Bauprofilen (darunter auch keinem) baut.
Mit anderen Worten: Falls der Absatz eines Binärpaketes mit einem nicht leeren Feld
Build-Profiles kommentiert wird, dann wird dieses Binärpaket erstellt, falls und
nur falls der Ausdruck in konjunktiver Normalform sich auf »wahr« berechnet.
Essential: yes|no
Build-Essential: yes|no
Multi-Arch: same|foreign|allowed|no
Tag: Liste-von-Markierungen
Description: Kurzbeschreibung (empfohlen)
Diese Felder sind in der Handbuchseite deb-control(5) beschrieben, da sie wörtlich
in die control-Datei des Binärpakets kopiert werden.
Depends: Paketliste
Pre-Depends: Paketliste
Recommends: Paketliste
Suggests: Paketliste
Breaks: Paketliste
Enhances: Paketliste
Replaces: Paketliste
Conflicts: Paketliste
Provides: Paketliste
Built-Using: Paketliste
Diese Felder geben Beziehungen zwischen Paketen an. Sie werden in der Handbuchseite
deb-control(5) erläutert. In debian/control können diese Felder auch mit einem
abschließenden Komma enden (seit Dpkg 1.10.14), Architekturspezifikations- und
-einschränkungsformeln enthalten, die alle beim Erstellen von deb-control(5)
reduziert werden.
Subarchitecture: Wert
Kernel-Version: Wert
Installer-Menu-Item: Wert
Diese Felder werden im Debian-Installer in udebs verwandt und werden normalerweise
nicht benötigt. Lesen Sie /usr/share/doc/debian-installer/devel/modules.txt aus dem
Paket debian-installer für weitere Informationen über sie.
BENUTZERDEFINIERTE FELDER
Es ist erlaubt, zusätzliche benutzerdefinierte Felder zu der Steuerdatei hinzuzufügen. Die
Werkzeuge werden diese Felder ignorieren. Falls Sie möchten, dass diese Felder in die
Ausgabedateien, wie das Binärpaket, rüberkopiert werden sollen, müssen Sie ein angepasstes
Namensschema verwenden: Die Felder sollten mit einem X, gefolgt von Null oder mehreren
Buchstaben aus SBC und einem Gedankenstrich, beginnen.
S Das Feld wird in der Steuerdatei des Quellpakets auftauchen, siehe dsc(5).
B Das Feld wird in der Steuerdatei des Binärpakets auftauchen, siehe deb-control(5).
C Das Feld wird in der Steuerdatei des Uploads (.changes) auftauchen, siehe
deb-changes(5).
Beachten Sie, dass die Präfixe X[SBC]- abgeschnitten werden, wenn die Felder in die
Ausgabedateien rüberkopiert werden. Ein Feld XC-Approved-By wird als Approved-By in der
.changes-Datei und nicht in der Steuerdatei des Binär- und Quellpakets auftauchen.
Beachten Sie, dass diese Benutzer-definierten Felder den globalen Namensraum nutzen werden
und somit in der Zukunft mit offiziell erkannten Feldern kollidieren könnten. Um solche
möglichen Situationen zu vermeiden, können Sie den Feldern Private-, wie in
XB-Private-Neues-Feld, voranstellen.
BEISPIEL
# Kommentar
Source: dpkg
Section: admin
Priority: required
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
# dieses Feld wird in das Binär- und Quellpaket kopiert
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
# dies ist ein spezielles Feld im Binärpaket
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: 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.
SIEHE AUCH
deb-control(5), deb-version(7), dpkg-source(1)
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2004, 2006-2019 von Helge Kreutzmann
<debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de> und 2008 von Sven
Joachim <svenjoac@gmx.de> angefertigt. Diese Übersetzung ist Freie Dokumentation; lesen
Sie die GNU General Public License Version 2 oder neuer für die Kopierbedingungen. Es gibt
KEINE HAFTUNG.