deb-src-control(5) dpkg suite deb-src-control(5)
BEZEICHNUNG
deb-src-control - Dateiformat der Hauptsteuerdatei von Debian-
Quellpaketen
ÜBERSICHT
debian/control
BESCHREIBUNG
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.
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 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.
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
(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>.
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 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.
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
/usr/share/doc/dpkg/spec/rootless-builds.txt, deb822(5), deb-
control(5), deb-version(7), dpkg-source(1)
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2004, 2006-2023 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.
1.21.22 2023-05-11 deb-src-control(5)
Generated by dwww version 1.15 on Sat Jun 29 01:38:33 CEST 2024.