Ubuntu Manpage: deb-src-control - Dateiformat der Hauptsteuerdatei von Debian-Quellpaketen

bezeichnung
übersicht
beschreibung
quellpaket-felder
binärpaket-felder
benutzerdefinierte felder
beispiel
siehe auch
übersetzung

Provided by: dpkg-dev_1.19.0.5ubuntu2.4_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 alphanumerischen Zeichen 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 short-description
Langbeschreibung
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
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).

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://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
       # 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-2017 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.