deb-buildinfo - Format der Bauinformationsdateien von Debian
ÜBERSICHT
Dateiname.buildinfo
Jeder Bau eines Debian-Quellpakets kann die Bauinformationen in
einer .buildinfo-Steuerdatei aufzeichnen. Diese enthält eine
Reihe von Feldern. Jedes Feld beginnt mit einer Markierung, wie
Source oder Binary (Groß-/Kleinschreibung ist egal),
gefolgt von einem Doppelpunkt und dem Inhalt des Feldes. Felder werden nur
durch Feldmarkierungen begrenzt. Mit anderen Worten, Felder können
mehrere Zeilen umfassen, aber die Installationswerkzeuge werden im
Allgemeinen die Zeilen bei der Verarbeitung des Feldinhaltes zusammenfassen
(außer im Falle der mehrzeiligen Felder Binary-Only-Changes,
Installed-Build-Depends, Environment, Checksums-Md5,
Checksums-Sha1 und Checksums-Sha256, siehe unten).
Die Steuerdaten können in eine Signatur mit einer wie in
RFC4880 spezifizierten OpenPGP-ASCII-Hülle eingeschlossen sein.
Der Name der .buildinfo-Datei wird von der Art des Baus
abhängen und wird so spezifisch wie notwendig sein, aber nicht mehr;
für einen Bau, der any enthält, wird der Name
Quellname_Binärversion_Arch.buildinfo
oder andernfalls für einen Bau, der all enthält, wird
der Name
Quellname_Quellversion_all.buildinfo oder
andernfalls für einen Bau, der source enthält, wird der
Name
Quellname_Binärversion_source.buildinfo
lauten.
- Format:
Formatversion (verpflichtend)
- Das Wert dieses Feldes gibt die Formatversion der Datei an. Die Syntax des
Feldwertes ist eine Versionsnummer mit einer Haupt- und einer
Nebenkomponente. Rückwärtsinkompatible Änderungen im
Format führen zu einer Erhöhung der Hauptversion und
rückwärtskompatible Änderungen (wie die Aufnahme
neuer Felder) führen zu einer Erhöhung der Nebenversion. Die
aktuelle Formatversion ist 1.0.
- Source:
Quellname [(Quellversion)]
(verpflichtend)
- Der Name des Quellpakets. Falls sich die Quellversion von der
Binärversion unterscheidet, folgt dem Quellnamen in Klammern
eine Quellversion. Dies kann passieren, falls der Bau für
einen rein-binären, nicht-Betreuer-Upload ist.
- Binary:
Binärpaketliste (verpflichtend)
- Das gefaltete Feld gibt eine durch Leerzeichen getrennte Liste von
gebauten Binärpaketen an.
- Architecture:
Architekturliste (verpflichtend)
- Dieses durch Leerzeichen getrennte Feld führt die Architekturen der
derzeit gebauten Dateien auf. Typische Architekturen sind amd64,
armel, i386 usw. Beachten Sie, dass der Wert all
für architekturunabhängige Pakete gedacht ist. Falls die
Quelle für das Paket auch gebaut wird, ist der besondere Eintrag
source auch vorhanden. Architektur-Platzhalter dürfen in der
Liste niemals auftauchen.
- 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.
- Binary-Only-Changes:
- Changelog-Eintrag
- Das mehrzeilige Feld enthält den aneinandergehängten Text
des Changelog-Eintrages eines rein binären, nicht-Betreuer-Uploads
(binNMU), sofern dies der Fall ist. Um ein gültiges mehrzeiliges
Feld zu erhalten, werden leere Zeilen durch ein einzelnen Satzpunkt
(‚.’) ersetzt und alle Zeilen mit einem Leerzeichen
eingerückt. Der genaue Inhalt hängt vom Changelog-Format
ab.
- Checksums-Md5:
(verpflichtend)
- Checksums-Sha1:
(verpflichtend)
- Checksums-Sha256:
(verpflichtend)
-
Prüfsumme Größe Dateiname
- Diese mehrzeiligen Felder enthalten eine Liste von Dateien mit einer
Prüfsumme und Größe für jede. Diese Felder
haben die gleiche Syntax und unterscheiden sich nur im verwandten
Prüfsummenalgorithmus: MD5 für Checksums-Md5, SHA-1
für Checksums-Sha1 und SHA-256 für
Checksums-Sha256.
Die erste Zeile des Feldwertes (der Teil auf der gleichen
Zeile wie der durch einen Doppelpunkt gefolgte Feldname) ist immer leer.
Der Inhalt des Feldes wird durch Fortsetzungszeilen ausgedrückt,
eine Zeile pro Datei. Jede Zeile besteht aus durch Leerzeichen
getrennten Einträgen, die die Datei beschreiben: der
Prüfsumme, der Dateigröße und dem Dateinamen.
Diese Datei führt alle Dateien auf, aus denen der Bau
besteht.
- Build-Origin:
Name
- Der Name der Distribution, aus der dieses Paket ursprünglich
stammt.
- Build-Architecture:
Arch (verpflichtend)
- Die Debian-Architektur für die Installation, unter der das Paket
gebaut wurde. Typische Architekturen sind amd64, armel,
i386, usw.
- Build-Date:
Baudatum
- Das Datum, an dem das Paket letztmalig gebaut wurde. Es muss im gleichen
Format wie in einem Eintrag bei deb-changelog(5) sein.
- Build-Kernel-Version:
Bau-Kernel-Version
- Die Veröffentlichung und die Version (in einem nicht festgelegten
Format) des auf dem Bausystem laufenden Kernels. Dieses Feld ist nur
vorhanden, falls der Bauende es explizit angefordert hat, um zu
verhindern, dass vertrauliche Informationen versehentlich
veröffentlicht werden.
- Build-Path:
Baupfad
- Der absolute Baupfad, der dem entpackten Quellbaum entspricht. Dieses Feld
ist nur vorhanden, falls der Lieferant das Feld über ein Muster
freigeschaltet hat, um zu verhindern, dass vertrauliche Informationen
versehentlich veröffentlicht werden.
Unter Debian und abgeleiteten Distributionen werden nur
Baupfade, die mit /build/ beginnen, dieses Feld ausgeben.
- Build-Tainted-By:
- Taint-Begründungsliste
- Dieses gefaltete Feld enthält eine durch Leerzeichen getrennte,
nicht abschließende Liste von Markierungen (die durch
alphanumerische und Bindestrichzeichen aufgebaut werden), die
identifizieren, warum der aktuelle Bau unsauber (tainted) wurde (seit Dpkg
1.19.5).
- Unter Debian und abgeleiteten Distributionen können die folgenden
Begründungsmarkierungen ausgegeben werden:
- merged-usr-via-symlinks
- Das System hat ein mittels Symlinks zusammengeführtes /usr.
Dies wird dpkg-query, dpkg-statoverride,
dpkg-trigger, update-alternatives und weitere Werkzeuge, die
Pfadnamen als Schlüssel in ihren Datenbanken verwenden,
durcheinanderbringen, da es Dateisystem-Alias-Probleme erzeugt und bringt
das Verständnis, das dpkg in seiner Datenbank aufnotiert
hat, durcheinander. Für Bausysteme, die Pfadnamen auf bestimmte
Programme oder Bibliotheken auf den enstandenen Artefakten hartkodieren,
kann dies auch zu Paketen führen, die mit nicht
zusammengeführten /usr-Dateisystemen inkompatibel sind.
- usr-local-has-configs
- Das System hat Konfigurationsdateien unter /usr/local/etc.
- usr-local-has-includes
- Das System hat Header-Dateien unter /usr/local/include.
- usr-local-has-programs
- Das System hat Programme unter /usr/local/bin oder
/usr/local/sbin.
- usr-local-has-libraries
- Das System hat Bibliotheken, entweder statische oder Laufzeit-, unter
/usr/local/lib.
- Installed-Build-Depends:
(verpflichtend)
- Paketliste
- Die Liste der installierten und konfigurierten Pakete, die den Bauprozess
des Pakets beeinflussen könnten.
Die Liste besteht aus jedem Paketnamen, optional
architekturqualifiziert für fremde Architekturen, mit einer
genauen Versionseinschränkung, getrennt durch Kommata.
Die Liste enthält alle essenziellen Pakete, die in
Quell-Steuerfeldern Build-Depends, Build-Depends-Arch,
Build-Depends-Indep aufgeführten Pakete, alle
Lieferanten-spezifischen eingebauten Abhängigkeiten und alle ihre
rekursiven Abhängigkeiten. Unter Debian und abgeleiteten
Distributionen ist die eingebaute Abhängigkeit
build-essential.
Für Abhängigkeiten aus den Quellsteuerfeldern
werden alle Abhängigkeitsalternativen und alle Anbieter
abhängiger virtueller Pakete mit aufgenommen.
- Umgebung
- Variablenliste
- Die Liste der Umgebungsvariablen, die bekanntermaßen den
Paketbauprozess beeinflussen, wobei jede Umgebungsvariable von einem
Gleichheitszeichen (,=’) und dem mit
Rückwärtsschrägstrichen (,\\’) maskierten Wert
in doppelten Anführungszeichen (,=’) gefolgt wird.
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2004, 2006-2020 von Helge
Kreutzmann <debian@helgefjell.de>, 2007 von Florian Rehnisch
<eixman@gmx.de>, 2008 von Sven Joachim <svenjoac@gmx.de> und
2019,2020 von Mario Blättermann <mario.blaettermann@gmail.com>
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.