plucky (5) deb-src-control.5.gz

Provided by: dpkg-dev_1.22.15ubuntu1_all bug

BEZEICHNUNG

       deb-src-control - Dateiformat der Vorlagensteuerdatei von Debian-Quellpaketen

ÜBERSICHT

       debian/control

BESCHREIBUNG

       Jedes Debian-Quellpaket enthält die Vorlagenquellsteuerdatei „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
       heißt Quellpaketabsatz und führt alle allgemeinen Informationen über das Quellpaket auf, während alle
       folgende Absätze Binärpaketabsatz heißen und genau ein Binärpaket pro Absatz beschreiben. 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 muss 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 muss 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.

       Build-Driver: Treibername
           Dieses experiementelle Feld legt den Namen des Bautreibers fest, der zum Bau dieses Pakets verwendet
           werden soll. Falls nicht angegeben, ist die Vorgabe für Treibername debian-rules.

           Dieses Feld wird seit Dpkg 1.22.7 unterstützt.

       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. Dies ist in dpkg-build-api Stufe >=1
               oder seit Dpkg 1.22.13 die Vorgabe.

           binary-targets
               Die Binärziele müssen immer unter (fake)root ausgeführt werden. Dieser Wert ist in dpkg-build-api
               Stufe 0 bis Dpkg 1.22.13 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.

           Falls entfallen ist die Vorgabe von section unknown (seit Dpkg 1.22.13).

           Die akzeptierten Werte hängen von den jeweiligen Distributionsrichtlinien ab.

       Priority: Priorität
           Setzt die Bedeutung dieses Pakets in Bezug zu dem Gesamtsystem. Die bekannten Prioritäten sind
           required, important, standard, optional, extra und unknown, es können aber auch andere Werte verwandt
           werden.

           Falls entfallen ist die Vorgabe von priority optional (seit Dpkg 1.22.13).

           Wie diese Werte angewandt werden, hängt von den jeweiligen Distributionsrichtlinien ab.

       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: 4.7.0
        Build-Depends:
         debhelper-compat (= 13),
         debhelper (>= 13.10~),
         pkgconf,
         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:
         binutils,
         bzip2,
         cpio (>= 2.4.2-2),
        # This is a comment in the middle of a field value.
         dpkg (>= 1.14.6),
         libtimedate-perl,
         lzma,
         make,
         patch (>= 2.2-1),
         perl-modules,
         perl5,
        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-2025 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.