Provided by: dpkg-dev_1.19.0.5ubuntu2.4_all 
BEZEICHNUNG
deb-control - Dateiformat der Hauptsteuerdatei von binären Debian-Paketen
ÜBERSICHT
control
BESCHREIBUNG
Jedes binäre Debian-Paket enthält die Hauptsteuerdatei control, die eine Reihe von Feldern enthält. Jedes
Feld beginnt mit einer Markierung, wie Package oder Version (Groß-/Kleinschreibung egal), gefolgt von
einem Doppelpunkt und dem Körper des Feldes. Felder werden nur durch die Feldmarkierungen abgegrenzt. Mit
anderen Worten, Feldtexte können mehrere Zeilen überspannen, aber die Installationswerkzeuge werden im
Allgemeinen die Zeilen bei der Verarbeitung des Feldkörpers zusammenfassen (mit Ausnahme des
Description-Feldes, sehen Sie dazu unten).
FELDER
Package: Paketname (verpflichtend)
Der Wert dieses Feldes bestimmt den Paketnamen und wird von den meisten Installationswerkzeugen
verwendet, um Dateinamen zu erstellen.
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.
Version: Versionszeichenkette (verpflichtend)
Typischerweise ist das die Original-Paketversionsnummer, in der Form, die der Programmautor
verwendet. Es kann auch eine Debian-Revisionsnummer enthalten (für nicht aus Debian stammende
Pakete). Das genaue Format und der Sortieralgorithmus sind in deb-version(7) beschrieben.
Maintainer: Vollständiger-Name-und-E-Mail (empfohlen)
Sollte in dem Format „Joe Bloggs <jbloggs@foo.com>“ sein und ist typischerweise die Person, die
das Paket erstellt hat, im Gegensatz zum Autor der Software, die paketiert wurde.
Description: Kurzbeschreibung (empfohlen)
Langbeschreibung
Das Format der Paketbeschreibung 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.
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.
Installed-Size: Größe
Die ungefähre Gesamtgröße der vom Paket installierten Dateien, in Einheiten von KiB.
Essential: yes|no
Dieses Feld wird normalerweise nur benötigt, wenn die Antwort yes lautet. Es bezeichnet ein Paket,
das für den ordnungsgemäßen Betrieb des Systems benötigt wird. Dpkg oder jedes andere
Installationswerkzeug wird es nicht erlauben, ein Essential-Paket zu entfernen (zumindestens nicht
ohne die Verwendung einer der »force«-Optionen).
Build-Essential: yes|no
Dieses Feld wird normalerweise nur benötigt, wenn die Antwort yes lautet und es wird
typischerweise durch die Archivsoftware eingefügt. Es vermerkt ein Paket, das zum Bau anderer
Pakete benötigt wird.
Architecture: arch|all (empfohlen)
Die Architektur spezifiziert den Hardwaretyp für den dieses Paket kompiliert wurde. Geläufige
Architekturen sind amd64, armel, i386, powerpc usw. Beachten Sie, dass der Wert all für Pakete
gedacht ist, die Architektur-unabhängig sind. Einige Beispiele hierfür sind Shell- und
Perl-Skripte und Dokumentation.
Origin: Name
Der Name der Distribution, aus der dieses Paket ursprünglich stammt.
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.
Homepage: URL
Die URL des Original- (Upstream-)Projekts.
Tag: Liste-von-Markierungen
Liste der unterstützten Markierungen (»Tags«), die die Eigenschaften des Pakets beschreiben. Die
Beschreibung und die Liste der unterstützten Markierungen kann in dem Paket debtags gefunden
werden.
Multi-Arch: no|same|foreign|allowed
Dieses Feld wird zum Anzeigen verwandt, wie sich das Paket auf einer Multi-Arch-Installation
verhalten soll.
no Dieser Wert ist die Vorgabe, falls das Feld nicht angegeben ist. In diesem Fall ist das
Hinzufügen des Feldes mit dem expliziten Wert no im allgemeinen nicht notwendig.
same Das Paket ist mit sich selbst koinstallierbar, darf aber nicht dazu verwandt werden, die
Abhängigkeit irgendeines Pakets von einer anderen Architektur auf sich zu erfüllen.
foreign
Das Paket ist nicht mit sich selbst koinstallierbar, aber es sollte erlaubt sein, die
nichtarchitekturabhängige Abhängigkeit eines Pakets von einer anderen Architektur auf sich
zu erfüllen (falls eine Abhängigkeit explizit architekturqualifiziert wurde, dann wird der
Wert foreign ignoriert).
allowed
Dies erlaubt es inversen Abhängigkeiten, in ihrem Feld Depends anzuzeigen, dass sie Pakete
von einer fremden Architektur akzeptieren, indem sie den Paketnamen mit :any qualifizieren.
Hat weiter keinen Effekt.
Source: Quellname [(Quellversion)]
Der Name des Quellpakets, aus dem dieses Binärpaket stammt, falls es sich vom Namen des Pakets
selbst unterscheidet. Falls die Quellversion sich von der Binärversion unterscheidet, folgt dem
Quellnamen in Klammern eine Quellversion. Dies kann zum Beispiel bei einem rein-binären, nicht
Betreuer-Upload passieren, oder wenn mittels »dpkg-gencontrol -v« eine andere Binärversion gesetzt
wird.
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.
Depends: Paketliste
Liste von Paketen, die benötigt werden, damit dieses Paket eine nicht-triviale Menge an Funktionen
anbieten kann. Die Paketverwaltungssoftware wird es nicht erlauben, dass ein Paket installiert
wird, falls die in seinem Depends-Feld aufgeführten Pakete nicht installiert sind (zumindestens
nicht ohne Verwendung der »Force«-Optionen). Bei einer Installation werden Postinst-Skripte von
Paketen, die im Feld Depends aufgeführt sind, vor den Postinst-Skripten der eigentlichen Pakete
ausgeführt. Bei der gegenteiligen Operation, der Paket-Entfernung, wird das Prerm-Skript eines
Paketes vor den Prerm-Skripten der Pakete ausgeführt, die im Feld Depends aufgeführt sind.
Pre-Depends: Paketliste
Liste an Paketen die installiert und konfiguriert sein müssen, bevor dieses Paket installiert
werden kann. Dies wird normalerweise in dem Fall verwendet, wo dieses Paket ein anderes Paket zum
Ausführen seines preinst-Skriptes benötigt.
Recommends: Paketliste
Liste an Paketen, die in allen, abgesehen von ungewöhnlichen, Installationen zusammen angefunden
würden. Die Paketverwaltungssoftware wird den Benutzer warnen, falls er ein Paket ohne die im
Recommends-Feld aufgeführten Pakete installiert.
Suggests: Paketliste
Liste an Paketen die einen Bezug zu diesem haben und vielleicht seine Nützlichkeit erweitern
könnten, aber ohne die das zu installierende Paket perfekt sinnvoll ist.
Die Syntax der Depends, Pre-Depends, Recommends und Suggests-Felder ist eine Liste von Gruppen von
alternativen Paketen. Jede Gruppe ist eine Liste von durch vertikale Striche (oder „Pipe“-Symbole) ‚|’
getrennte Pakete. 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
gefolgt von einer Architektur-Spezifikation, die nach einem Doppelpunkt »:« angehängt wird, optional
gefolgt von einer Versionsnummer-Spezifikation in Klammern.
Eine Architektur-Spezifikation kann eine echte Debian-Architektur sein (seit Dpkg 1.16.5) oder any (seit
Dpkg 1.16.2). Falls sie fehlt, ist die Vorgabe die aktuelle Programmpaketarchitektur. Ein echter
Debian-Architekturname wird genau auf diese Architektur für diesen Paketnamen passen, any wird auf jede
Architektur für diesen Paketnamen passen, falls das Paket als Multi-Arch: allowed markiert wurde.
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.
Breaks: Paketliste
Liste Paketen auf, die von diesem Paket beschädigt werden, zum Beispiel in dem sie Fehler
zugänglich machen, wenn sich das andere Paket auf dieses Paket verlässt. Die
Paketverwaltungssoftware wird es beschädigten Paketen nicht erlauben, sich zu konfigurieren; im
Allgemeinen wird das Problem behoben, indem ein Upgrade des im Breaks-Feld aufgeführten Pakets
durchgeführt wird.
Conflicts: Paketliste
Liste an Paketen, die mit diesem in Konflikt stehen, beispielsweise indem beide Dateien den
gleichen Namen enthalten. Die Paketverwaltungssoftware wird es nicht erlauben, Pakete, die in
Konflikt stehen, gleichzeitig zu installieren. Zwei in Konflikt stehende Pakete sollten jeweils
eine Conflicts-Zeile enthalten, die das andere Paket erwähnen.
Replaces: Paketliste
Liste an Paketen, von denen dieses Dateien ersetzt. Dies wird dazu verwendet, um diesem Paket zu
erlauben, Dateien von einem anderen Paket zu ersetzen und wird gewöhnlich mit dem Conflicts-Feld
verwendet, um die Entfernung des anderen Paketes zu erlauben, falls dieses auch die gleichen
Dateien wie das im Konflikt stehende Paket hat.
Die Syntax von Breaks, Conflicts und Replaces ist eine Liste von Paketnamen, getrennt durch Kommata (und
optionalen Leerraumzeichen). Im Breaks- und Conflicts-Feld sollte das Komma als „ODER“ gelesen werden.
Eine optionale Architektur-Spezifikation kann mit der gleichen Syntax wie oben an den Paketnamen
angehängt werden; der Vorgabewert ist allerdings any statt der Architektur des Programms. Eine optionale
Version kann auch mit der gleichen Syntax wie oben für die Breaks-, Conflicts- und Replaces-Felder
angegeben werden.
Enhances: Paketliste
Dies ist eine Liste von Paketen, die dieses Paket erweitert. Es ist ähnlich Suggests, aber in der
umgekehrten Richtung.
Provides: Paketliste
Dies ist eine Liste von virtuellen Paketen, die dieses Paket bereitstellt. Gewöhnlich wird dies
verwendet, wenn mehrere Pakete alle den gleichen Dienst bereitstellen. Beispielsweise können
Sendmail und Exim als Mailserver dienen, daher stellen sie ein gemeinsames Paket
(„mail-transport-agent“) bereit, von dem andere Pakete abhängen können. Dies erlaubt es Sendmail
oder Exim als gültige Optionen zur Erfüllung der Abhängigkeit zu dienen. Dies verhindert, dass
Pakete, die von einem E-Mail-Server abhängen, alle Paketnamen für alle E-Mail-Server wissen und
‚|’ zur Unterteilung der Liste verwenden müssen.
Die Syntax von Provides ist eine Liste von Paketnamen, getrennt durch Kommata (und optionalen
Leerraumzeichen). Eine optionale Architektur-Spezifikation kann mit der gleichen Syntax wie oben an den
Paketnamen angehängt werden. Falls diese fehlt, ist die Vorgabe die binäre Paketarchitektur. Eine
optionale genaue (identisch mit) Version kann auch mit der gleichen Syntax wie oben angegeben werden
(seit Dpkg 1.17.11 berücksichtigt).
Built-Using: Paketliste
Dieses Feld führt zusätzliche Quellpakete auf, die während des Baus des Binärpakets verwandt
wurden. Dies dient als Hinweis für die Archivverwaltungssoftware, dass zusätzliche Quellpakete
vorhanden bleiben müssen, während dieses Binärpaket betreut wird. Dieses Feld muss eine Liste von
Quellpaketnamen enthalten, bei denen eine strenge Versionsbeziehung ‚=’ angegeben ist. Beachten
Sie, dass die Archivverwaltungssoftware wahrscheinlich einen Upload ablehnen wird, bei dem eine
Built-Using-Beziehung angegeben wurde, die innerhalb des Archivs nicht erfüllt werden kann.
Built-For-Profiles: Profilliste (veraltet)
Dieses Feld legte eine durch Leerraumzeichen getrennte Liste von Bauprofilen fest, unter denen
dieses Programmpaket gebaut wurde (von Dpkg 1.17.2 bis 1.18.18). Die bisher in diesem Feld
gefundenen Informationen können jetzt in der Datei .buildinfo gefunden werden, die es ersetzt.
Auto-Built-Package: Begründungsliste
Dieses Feld legt eine durch Leerraumzeichen getrennte Liste von Begründungen fest, warum dieses
Paket automatisch erstellt wurde. Binärpakete, die mit diesem Feld markiert wurden, werden nicht
in der Hauptquellsteuerdatei debian/control auftauchen. Die einzige derzeit verwandte Begründung
ist debug-symbols.
BEISPIEL
# Comment
Package: grep
Essential: yes
Priority: required
Section: base
Maintainer: Wichert Akkerman <wakkerma@debian.org>
Architecture: sparc
Version: 2.4-1
Pre-Depends: libc6 (>= 2.0.105)
Provides: rgrep
Conflicts: rgrep
Description: GNU grep, egrep und fgrep.
Die GNU-Familie der Grep-Werkzeuge könnte die »schnellste im Westen« sein.
GNU Grep basiert auf einem schellen »lazy-state deterministic matcher«
(rund zweimal so schnell wie der standardmäßige Unix-Egrep) hybridisiert
mit einer Boyer-Moore-Gosper-Suche für eine feste Zeichenkette, die
unmöglichen Text von der Betrachtung durch den vollen »Matcher« verhindert
ohne notwendigerweise jedes Zeichen anzuschauen. Das Ergebnis ist
typischerweise um ein mehrfaches Schneller als Unix Grep oder Egrep.
(Reguläre Ausdrücke, die Rückreferenzierungen enthalten, werden allerdings
langsamer laufen.)
SIEHE AUCH
deb(5), deb-version(7), debtags(1), dpkg(1), dpkg-deb(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.
1.19.0.5 2022-05-25 deb-control(5)