deb-src-control - Dateiformat der Hauptsteuerdatei von Debian-Quellpaketen
debian/control
Jedes Debian-Quellpaket enthält eine Hauptdatei „
debian/control“. Deren
deb822(5)-Format ist eine
Obermenge der in Debian-Binärpaketen ausgelieferten
control-Datei, siehe
deb-control(5).
Diese Datei enthält mindestens zwei Absätze, 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
(Groß-/Kleinschreibung ist relevant, außer anders angegeben) 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.
-
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
<[email protected]>“ 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 die 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 Feldes 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 darstellbaren
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 das Paket in eine
Kategorie einordnet, 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. Jedem Paketnamen folgt optional eine
Architekturspezifikation, 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
Kommata-getrennte 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 Versionsnummerangabe
in Klammern, eine Architekturspezifikation in eckigen Klammern und einer
Einschränkungsformel, die aus einer oder mehr Listen von Profilnamen in
spitzen Klammern besteht.
Eine Architekturspezifikation 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 disjunkten 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.
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 (einschließlich der spitzen
Klammern).
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.
-
Protected: yes|no
-
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
-
Static-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. Für
weitere Informationen über sie, siehe
<https://salsa.debian.org/installer-team/debian-installer/-/raw/master/doc/devel/modules.txt>.
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
Bindestrich, 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 benutzerdefinierten 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.
# Kommentar
Source: dpkg
Section: admin
Priority: required
Maintainer: Dpkg Developers <[email protected]>
# 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 <[email protected]>
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.
/usr/share/doc/dpkg/spec/rootless-builds.txt,
deb822(5),
deb-control(5),
deb-version(7),
dpkg-source(1)
Die deutsche Übersetzung wurde 2004, 2006-2023 von Helge Kreutzmann
<
[email protected]>, 2007 von Florian Rehnisch <
[email protected]>
und 2008 von Sven Joachim <
[email protected]> 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.