Provided by: dpkg-dev_1.21.1ubuntu2.3_all bug

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 für den ordnungsgemäßen Systemstart 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 den ordnungsgemäßen Betrieb des Systems benötigt wird.
           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. 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 (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 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 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-2021 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.