Provided by: dpkg-dev_1.22.0ubuntu1.1_all 
BEZEICHNUNG
deb-control - Dateiformat der Hauptsteuerdatei von binären Debian-Paketen
ÜBERSICHT
DEBIAN/control
BESCHREIBUNG
Jedes Debian-Binärpaket enthält eine Datei control in seinem control-Element. Ihr
deb822(5)-Format ist eine Teilmenge der Hauptdatei debian/control in dem Debian-
Quellpaket, siehe deb-src-control(5).
Diese Datei enthält eine Reihe von Feldern. Jedes Feld beginnt mit einer Markierung, wie
Package oder Version (Groß-/Kleinschreibung egal), gefolgt von einem Doppelpunkt und dem
Inhalt des Feldes (Groß-/Kleinschreibung ist relevant, außer anders angegeben). 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 Feldinhaltes 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 mit
einem Leerzeichen beginnen und Leerzeilen in der Langbeschreibung müssen einen
einzelnen ‚.’ hinter dem einleitenden Leerzeichen enthalten.
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.
Installed-Size: Größe
Die ungefähre Gesamtgröße der vom Paket installierten Dateien, in Einheiten von KiB.
Der zur Berechnung des Größe verwandte Algorithmus ist in deb-substvars(5)
beschrieben.
Protected: yes|no
Dieses Feld wird normalerweise nur benötigt, wenn die Antwort yes lautet. Es
bezeichnet ein Paket, das hauptsächlich für den ordnungsgemäßen Systemstart oder für
angepasste systemlokale Metapakete benötigt wird. dpkg(1) oder jedes andere
Installationswerkzeug wird es nicht erlauben, ein Protected-Paket zu entfernen
(zumindest nicht ohne die Verwendung einer der „force“-Optionen).
Unterstützt seit Dpkg 1.20.1.
Essential: yes|no
Dieses Feld wird normalerweise nur benötigt, wenn die Antwort yes lautet. Es
bezeichnet ein Paket, das für das Paketierungssystem, für den ordnungsgemäßen Betrieb
des Systems im Allgemeinen oder während des Systemstarts benötigt wird (Letzteres
sollte allerdings stattdessen auf das Feld Protected konvertiert werden). dpkg(1) oder
jedes andere Installationswerkzeug wird es nicht erlauben, ein Essential-Paket zu
entfernen (zumindest 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 (verpflichtend)
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. Für weitere Informationen über sie, siehe
<https://salsa.debian.org/installer-team/debian-installer/-/raw/master/doc/devel/modules.txt>.
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 (zumindest 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
Aktion, 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 zusammen mit diesem in allen - außer in eher ungewöhnlichen -
Installationen enthalten wären. 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 seinen Nutzwert
vergrößern könnten, aber ohne die das zu installierende Paket dennoch sinnvoll nutzbar
ist.
Die Syntax der Felder Depends, Pre-Depends, Recommends und Suggests 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. Jedem Paketnamen folgt optional eine
Architekturspezifikation, die nach einem Doppelpunkt „:“ angehängt wird, optional gefolgt
von einer Versionsnummer-Spezifikation in Klammern.
Eine Architekturspezifikation 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
Listet 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 gleichen Namens 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 Architekturspezifikation 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 kennen 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 Architekturspezifikation 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 Abhängigkeitsfeld führt zu Zwecken der Lizenzerfüllung 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 durch Kommata getrennte
Liste von Quellpaketnamen enthalten, bei denen in Klammern eingeschlossen 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.
Static-Built-Using: Paketliste
Dieses Abhängigkeitsfeld führt zu Zwecken des statischen Bauens zusätzliche
Quellpakete auf, die während des Baus des Binärpakets verwandt wurden (zum Beispiel
Linken gegen statische Bibliotheken, Bauen für quellbasierte Sprachen wie Go oder
Rust, Verwendung von reinen Header-C/C++-Bibliotheken, Einschieben von Datenblöcken in
Code usw.). Dies ist zur Nachverfolgung nützlich, ob dieses Paket neu gebaut werden
muss, wenn hier aufgeführte Quellpakete aktualisiert wurden, beispielsweise aufgrund
von Sicherheitsaktualisierungen. Dieses Feld muss eine durch Kommata-getrenne Liste
von Quellpaketnamen enthalten, bei denen in Klammern eingeschlossen eine strenge
Versionsbeziehung ‚=’ angegeben ist.
Unterstützt seit Dpkg 1.21.3.
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 enthaltene 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.
Build-Ids: ELF-Baukennungsliste
Das Feld gibt eine durch Leerraum getrennte Liste von ELF-Baukennugen an. Dies sind
eindeutige Kennzeichner für semantisch identische ELF-Objekte, für jedes von diesen
innerhalb des Pakets.
Das Format oder die Art, jede Baukennung zu berechnen, ist designbedingt nicht
festgelegt.
BEISPIEL
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.)
FEHLER
Das Feld Build-Ids verwendet einen eher generischen Namen aus seinem ursprünglichen
Zusammenhang innerhalb eines ELF-Objektes, das einem sehr speziellen Zweck und
ausführbaren Format dient.
SIEHE AUCH
deb822(5), deb-src-control(5), deb(5), deb-version(7), debtags(1), dpkg(1), dpkg-deb(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.