ÜBERSICHT

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 <[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 den sich das Paket hält.

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.

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. 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, einer Architekturspezifikation in eckigen Klammern und einer Einschränkungsformel, die aus einer oder mehr Listen von Profilnamen in spitzen Klammern 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 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.

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.

Package-Type: deb|udeb

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.

Subarchitecture: Wert

Kernel-Version: Wert Installer-Menu-Item: Wert Diese Felder werden im Debian-Installer 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.

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 deklarieren die Beziehungen zwischen Paketen. Sie werden in der Handbuchseite deb-control(5) beschrieben.

BENUTZERDEFINIERTE FELDER

Es ist erlaubt, zusätzliche benutzerdefinierte Felder zu der control-Datei hinzuzufügen. Die Werkzeuge werden diese Felder ignorieren. Falls Sie möchten, dass die Felder in die Ausgabedateien, wie z.B. die Binärpakete, kopiert werden, müssen Sie ein angepasstes Namensschema verwenden: Die Felder sollten mit einem X, gefolgt von einem oder mehr der Buchstaben BCS und einem Gedankenstrich beginnen. Falls der Buchstabe B benutzt wird, wird das Feld in der Steuerdatei des Binärpakets auftauchen, siehe deb-control(5), beim Buchstaben S in der Quellpaketsteuerdatei wie sie von dpkg-source(1) erstellt wird und beim Buchstaben C in der hochgeladenen Datei control (.changes). Beachten Sie, dass die X[BCS]-Vorsilben beim Kopieren in die Ausgabedateien entfernt werden. Ein Feld XC-Approved-By wird als Approved-By in der Datei changes, aber nicht in den Steuerdateien des Quell- und Binärpakets 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 <[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://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 <[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.

ÜBERSETZUNG

Die deutsche Übersetzung wurde 2004, 2006-2016 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.