deb-control - Dateiformat der Hauptsteuerdatei von binären
Debian-Paketen
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).
- 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
- 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.
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.)
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.
Ü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.