sbuild – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

sbuild – Debian-Pakete aus dem Quellcode erstellen

ZUSAMMENFASSUNG

bauen [-h|--help | -V|--Version] [-v|- ausführlich | -q|--ruhig] [-D|--debuggen] [-A|--arch-all]
[--archive=Archiv] [-d|--dist=Verteilung] [-c|--chroot=Chroot] [--arch=Architektur]
[--arch-any | --no-arch-any] [--arch-all-only] [--build=Architektur]
[--host=Architektur] [--profiles=Profil[,...]] [-s|--Quelle] [--force-orig-source]
[--make-binNMU=Changelog-Eintrag] [--binNMU=NMU-Version] [--append-to-version=Schnur]
[--add-depends=Abhängigkeit] [--add-conflicts=Abhängigkeit] [--add-depends-arch=Abhängigkeit]
[--add-conflicts-arch=Abhängigkeit] [--add-depends-indep=Abhängigkeit] [--hinzufügen-
Konflikte-unabhängig=Abhängigkeit] [-m|--maintainer=Betreuer] [-e|--uploader=Uploader]
[-k|--keyid=Schlüssel-ID] [-j|--jobs=n] [--debbuildopt=ganz ohne irgendetwas tun oder drücken zu müssen.] [--debbuildopts=Optionen] [--dpkg-
source-opt=Optionen] [--dpkg-source-opts=Optionen] [-p|--purge=Purge-Modus]
[--purge-build=Purge-Modus] [--purge-deps=Purge-Modus] [--purge-session=Purge-Modus]
[-b|--Charge] [-n|--nolog] [--clean-source] [--no-clean-source] [--run-lintian]
[--no-run-lintian] [--lintian-opt=Optionen] [--lintian-opts=Optionen] [--run-piuparts]
[--no-run-piuparts] [--piuparts-opt=Optionen] [--piuparts-opts=Optionen]
[--piuparts-root-arg=Optionen] [--piuparts-root-args=Optionen] [--pre-build-commands=Schnur]
[--chroot-setup-commands=Schnur] [--build-deps-failed-commands=Schnur]
[--starting-build-commands=Schnur] [--finished-build-commands=Schnur]
[--build-failed-commands=Schnur] [--chroot-cleanup-commands=Schnur]
[--post-build-commands=Schnur] [--anything-failed-commands=Schnur]
[--log-external-command-output] [--log-external-command-error] [--setup-hook=Hook-Skript]
[--build-dep-resolver=Resolver] [--resolve-alternatives|--no-resolve-alternatives]
[--extra-package=package.deb] [--extra-repository=spec] [--extra-repository-key=Datei.asc]
[--build-path=Schnur] [PAKET[.dsc]]

BESCHREIBUNG

bauen erstellt Debian-Binärpakete aus der entsprechenden Debian-Quelle neu und installiert sie
etwaige fehlende Quellabhängigkeiten. Der Build erfolgt in einem dedizierten Clean Build
Umgebung (Chroot) und nicht auf dem Hostsystem.

bauen kann die Debian-Quelle über ein Netzwerk abrufen oder lokal verfügbar verwenden
Quellen.

Als Argument erhält sbuild ein zu verarbeitendes Paket PAKET[.dsc]. Dieses Argument ist in
die Form eines debianisierten Paketquellverzeichnisses, eines Quellpaketnamens zusammen mit
eine Version im Formular Paketversionoder eine .dsc-Datei. Wenn keine Argumente angegeben werden, wird die
Als Argument wird das aktuelle Arbeitsverzeichnis übergeben.

Für als Quellverzeichnisse angegebene Argumente wird zunächst dpkg-source ausgeführt, um eine Quelle zu erstellen
.dsc-Datei. Anschließend wird das Paket mit der erstellten .dsc-Datei erstellt. Für Argumente im Formular
Paketversion, apt wird zum Herunterladen des Quellpakets verwendet. Für Argumente, die als .dsc angegeben sind
Datei erstellt sbuild die Quellpakete direkt. Für .dsc-Dateien an entfernten Standorten gilt:
Quellpakete werden zuerst heruntergeladen und dann erstellt.

Es ist auch möglich, externe Befehle mit sbuild auszuführen. Siehe den Abschnitt EXTERNAL
BEFEHLE mehr dazu.

bauen sendet die Build-Protokolle per E-Mail an einen Benutzer. Die Konfiguration erfolgt über die Konfigurationsdateien
/etc/sbuild/sbuild.conf und ~/.sbuildrc. Ein Beispiel für sbuildrc ist verfügbar in
/usr/share/doc/sbuild/examples/example.sbuildrc. Ein benutzerdefinierter Pfad zu einer Konfigurationsdatei
kann auch durch Festlegen von angegeben werden SBUILD_CONFIG Umgebungsvariable zum Pfad hinzufügen
einer zusätzlichen Konfigurationsdatei.

Sie können entweder ein lokales Paket mit seiner .dsc-Datei oder ein Remote-Paket erstellen
Angabe einer expliziten Dpkg-Version.

Hinweis: Bei Verwendung von Schroot (empfohlen) muss die Chroot den Namen (oder Alias) des haben
die angegebene Verteilung wird verwendet; schroot verwendet eine Chroot namens $distribution-$arch-
bauen, $distribution-sbuild, $distribution-$arch or $Verteilung, in dieser Reihenfolge
Präferenz. Die Option -c oder --chroot kann verwendet werden, um die zu verwendende Chroot zu überschreiben. Wann
Wenn es für die Verwendung von sudo (veraltet) konfiguriert ist, sucht sbuild nach einem symbolischen Link zu einer Chroot mit dem
Gleicher Name wie die angegebene Distribution. sbuild verwendet einen Symlink zur gefundenen Chroot
in /etc/sbuild/chroot/$distribution, oder muss in einem Verzeichnis ausgeführt werden, das a enthält
chroot-$distribution Symlink zur Chroot (nicht empfohlen, aber für Rückwärtsfahrten gemacht).
Kompatibilität).

OPTIONAL

-h, --help
Zeigen Sie dieses Handbuch an.

-V, --Version
Versionsinformationen drucken.

--add-depends=Abhängigkeit

--add-conflicts=Abhängigkeit

--add-depends-arch=Abhängigkeit

--add-conflicts-arch=Abhängigkeit

--add-depends-indep=Abhängigkeit

--add-conflicts-indep=Abhängigkeit
Diese Optionen fügen dem zu erstellenden Quellpaket Build-Abhängigkeiten hinzu
Zusätzlich zu den Build-Abhängigkeitsinformationen, die in debian/control angegeben sind. Diese
Abhängigkeiten werden direkt mit den Build-Depends, Build-Conflicts,
Build-Depends-Arch, Build-Conflicts-Arch, Build-Depends-Indep und Build-Conflicts-
Unabhängige Abhängigkeiten bzw. Die Optionen können beliebig oft verwendet werden
mehrere Abhängigkeiten hinzufügen. Das Format ist identisch mit dem in
debian/control.

--arch=Architektur
Erstellen Sie mit der angegebenen Architektur. Ein Chroot namens $distribution-$arch-sbuild
or $distribution-arch gesucht wird, in dieser Reihenfolge der Präferenz. Der Chroot
muss entsprechend installiert und konfiguriert werden, um als diese Architektur zu erstellen, z
mit automatisierten Personality=linux32 um i386-Pakete auf einem amd64-System zu erstellen. Beachten Sie, dass
Diese Option entspricht „--host=architecture --build=architecture“.

--host=Architektur
Erstellen Sie mit der angegebenen Hostarchitektur. Wenn $host und $build nicht übereinstimmen, a
chroot benannt $distribution-$build-$host-sbuild or $distribution-$build-$host is
gesucht, zurückgreifend $distribution-$build-sbuild or $distribution-$build,
in dieser Reihenfolge der Präferenz. Diese Option ist nur für Cross-Building sinnvoll, wenn
Wird zusammen mit --build verwendet.

--build=Architektur
Erstellen Sie mit der angegebenen Build-Architektur. Diese Option ist nur nützlich für
Cross-Building bei Verwendung zusammen mit --host. Wenn --build nicht angegeben ist, wird die
Es wird von einer Standardsystemarchitektur ausgegangen.

-A, --arch-all
Erstellen Sie außerdem Architektur: alle Pakete, dh verwenden Sie dpkg-buildpackage -b anstelle von -B.

--no-arch-all
Erstellen Sie nicht alle Pakete, d. h. verwenden Sie stattdessen dpkg-buildpackage -B
-B. Diese Option ist das Gegenteil von --arch-all.

--arch-any
Build-Architektur: beliebige Pakete. Dies ist das Standardverhalten.

--no-arch-any
Erstellen Sie keine Architekturpakete. Diese Option ist das Gegenteil von --arch-any
und nur nützlich, wenn es zusammen mit --arch-all oder --source verwendet wird.

--arch-all-only
Erstellen Sie nur Architecture:all-Pakete, dh verwenden Sie dpkg-buildpackage -A anstelle von -B.
Der --arch=Architektur Mit der Option kann weiterhin die verwendete Architektur angegeben werden
um das Paket zu bauen.

-b, --Charge
Arbeiten Sie im Batchmodus, dh schreiben Sie während der Ausführung eine Build-Fortschrittsdatei und Dateien
beim Herunterfahren, um einen sauberen Neustart zu ermöglichen.

-c, --chroot=Chroot
Verwenden Sie die angegebene Chroot. Wenn nicht angegeben, ist der Standardwert der erste von
$distribution-$arch-sbuild, $distribution-sbuild, $distribution-$arch or
$Verteilung das existiert.

-d, --dist=Verteilung
Legen Sie die Verteilung für die Paketerstellung explizit fest. Dies wird die Auswahl treffen
Korrekte Chroot zu verwenden und legt auch den Wert des Feldes „Verteilung“ fest
erstellte .changes-Datei. Das Setzen dieser Option ist erforderlich, wenn Sie sbuild eine .dsc-Datei geben
Datei oder einen einfachen Quellpaketnamen zum Erstellen. Im letzteren Fall gibt es die an
Distribution, aus der das Quellpaket abgerufen wird.

--archive=Archiv
Kommunizieren Sie mit dem angegebenen Archiv.

-D, --debuggen
Debug-Ausgabe aktivieren.

--apt-clean
--no-apt-clean
Führen Sie apt-get clean in der Chroot aus (oder führen Sie es nicht aus), bevor Sie den Build ausführen.
Überschreiben der Standardeinstellung.

--apt-update
--no-apt-update
Führen Sie apt-get update in der Chroot aus (oder führen Sie es nicht aus), bevor Sie den Build ausführen.
Überschreiben der Standardeinstellung.

--apt-upgrade
--no-apt-upgrade
Führen Sie apt-get upgrade in der Chroot aus (oder führen Sie es nicht aus), bevor Sie den Build ausführen.
Überschreiben der Standardeinstellung.

--apt-distupgrade
--no-apt-distupgrade
Führen Sie apt-get distupgrade in der Chroot aus (oder führen Sie es nicht aus), bevor Sie den Build ausführen.
Überschreiben der Standardeinstellung.

-m, --maintainer=Betreuer
Geben Sie die Identität an, die für GPG-Signaturpakete verwendet und auch als verwendet werden soll
Betreuer für binäre NMUs. Dies erfordert normalerweise keine Einstellung (standardmäßig ist dies der Fall).
des Uploaders).

-e, --uploader=Uploader
Wird an dpkg-genchanges übergeben und zum Festlegen des Felds „Geändert von:“ in der .changes-Datei verwendet
Datei(en).

-k, --keyid=Schlüssel-ID
Wird an dpkg-genchanges übergeben und zum Festlegen des Schlüssels zum Signieren der .changes-Datei(en) verwendet.
Standardmäßig wird kein Schlüssel verwendet.

-j, --jobs=n
Anzahl der gleichzeitig auszuführenden Jobs. Weitergegeben an dpkg-buildpackage.

--debbuildopt=ganz ohne irgendetwas tun oder drücken zu müssen.
Übergeben Sie die angegebene Option direkt an dpkg-buildpackage.

--debbuildopts=Optionen
Übergeben Sie die angegebenen Optionen direkt an dpkg-buildpackage. Die Optionen sollten sein
durch Leerzeichen getrennt. Wenn Optionen Leerzeichen enthalten, verwenden Sie stattdessen --debbuildopt.

--dpkg-source-opt=Optionen
Übergeben Sie die angegebenen Optionen direkt an dpkg-source. Dies wird nur beim Erstellen verwendet
ein Quellpaket aus einem debianisierten Quellverzeichnis.
Anmerkungen: Der '-b'Option wird immer an dpkg-source übergeben.

--dpkg-source-opts=Optionen
Zusätzliche Optionen, die an vorhandene Optionen angehängt werden, die an dpkg-source übergeben werden.

--mail-log-to=E-Mail-Addresse
Senden Sie das Build-Protokoll an die angegebene E-Mail-Adresse. Dies überschreibt die $mailto
Konfigurationsoption.

--mailfrom=E-Mail-Addresse
E-Mail-Adresse, die als Absenderadresse für Build-Protokolle verwendet wird. Dies überschreibt die
$mailfrom Konfigurationsoption.

-n, --nolog
Erstellen Sie keine Paketprotokolldatei im $log_dir Verzeichnis und keine Build-Log-Datei,
aber drucke alles auf stdout. Versenden Sie auch keine Log-Mails.

-p, --purge=Purge-Modus
Komfortoption zum Einstellen Purge-Modus für Build-Verzeichnis, Build-Abhängigkeiten und
Session.

--profiles=Profil[,...]"
Geben Sie die von uns erstellten Profile als durch Kommas getrennte Liste an. Standardmäßig wird das Leerzeichen verwendet
Getrennte Liste der Profile in der DEB_BUILD_PROFILES variable Umgebung

--purge-build=Purge-Modus
Purge-Modus Legt fest, ob das Build-Verzeichnis nach einem Build gelöscht wird.
Mögliche Werte sind immer (Standard), niemals und erfolgreich.

--purge-deps=Purge-Modus
Purge-Modus Legt fest, ob die Build-Abhängigkeiten nach einem Build entfernt werden.
Mögliche Werte sind immer (Standard), niemals und erfolgreich.

--purge-session=Purge-Modus
Bereinigen Sie die Schroot-Sitzung nach einem Build. Dies ist nützlich in Verbindung mit
die --purge-build und --purge-deps Optionen bei der Verwendung von Snapshot-Chroots, da von
Standardmäßig wird der Snapshot gelöscht. Mögliche Werte sind immer (Standard), niemals,
und erfolgreich.

-s, --Quelle
Erstellen Sie auch das Quellpaket, dh verwenden Sie dpkg-buildpackage ohne -B.

--Keine Quelle
Erstellen Sie kein Quellpaket, dh verwenden Sie dpkg-buildpackage mit -B. Diese Option ist die
Gegenteil von --source.

--force-orig-source
Bei Verwendung mit in Verbindung mit -s erzwingt diese Option die Einbeziehung von
orig.tar.gz-Datei in der generierten .changes-Datei, auch in Fällen, in denen dies nicht der Fall wäre
normalerweise enthalten sein, also dpkg-buildpackage -sa verwenden.

--use-snapshot
Installiert den neuesten Snapshot-GCC-Compiler von gcc-Snapshot Paket und Änderungen
die Build-Umgebung, um den Snapshot-Compiler für den Build zu verwenden.

-v, - ausführlich
Seien Sie ausführlich, dh alle Informationen werden sowohl an stdout als auch an die Protokolldateien gesendet.

-q, --ruhig
Ruhig sein. Dies ist das Gegenteil von --verbose.

--make-binNMU=Changelog-Eintrag
Mit dieser Option bauen erstellt einen neuen Changelog-Eintrag in debian/changelog von
jedes Paket gebaut. Die Versionsnummer hat das Format für rein binäre NMUs
(siehe --binNMU); Der Betreuer wird auf den für konfigurierten Betreuernamen eingestellt bauen.
Changelog-Eintrag wird als Changelog-Eintrag nach „Binary-only non-“ verwendet.
Betreuer-Upload für ARCH – keine Quelländerungen“. Bitte beachten Sie, dass die Versionen in
die PACKAGE_VERSION[.dsc] Argumente müssen immer noch unverändert sein (Nicht-NMU-Argumente).
damit die Quellen gefunden werden können. Die Versionsnummer in Protokolldateien und E-Mails wird angezeigt
verändert von bauen automatisch.

--binNMU=NMU-Version
Die Versionsnummer der binären NMU. Dies sollte in Verbindung mit verwendet werden
--make-binNMU. Version ist eine einzelne Zahl für die (+bn) Format, das für Binärdateien verwendet wird
NMUs.

--append-to-version=Schnur
Diese Option ähnelt --make-binNMU, außer dass sie dem Benutzer die Möglichkeit gibt, etwas anzugeben
eine beliebige Zeichenfolge, die an die Versionsnummer angehängt wird (unmittelbar vor
'+' in der Debian-Revision, wenn auch --make-binNMU bereitgestellt wird).

--clean-source
Wenn Sie sbuild aus einem entpackten Quellbaum ausführen, führen Sie debian/rules aus
sauberes Ziel. Dies ist die Standardeinstellung und erfordert möglicherweise einige Build-Abhängigkeiten
auf dem Host installiert.

--no-clean-source
Wenn Sie sbuild aus einem entpackten Quellbaum heraus ausführen, führen Sie nicht aus
debian/rules bereinigt das Ziel, bevor das Quellpaket erstellt wird. Stellen Sie dies nur ein, wenn Sie
Beginnen Sie mit einer sauberen Kasse und Sie wissen, was Sie tun.

--run-lintian
Führen Sie Lintian nach einem erfolgreichen Build aus.

--no-run-lintian
Führen Sie Lintian nicht nach einem erfolgreichen Build aus. Wenn sbuild für die Ausführung von Lintian konfiguriert ist
Standardmäßig verhindert diese Option, dass Lintian ausgeführt wird.

--lintian-opt=Optionen
Führen Sie Lintian mit den angegebenen Optionen aus.

--lintian-opts=Optionen
Hängen Sie zusätzliche Optionen an vorhandene Optionen an, die an Lintian übergeben werden.

--run-piuparts
Führen Sie piuparts nach einem erfolgreichen Build aus.

--no-run-piuparts
Führen Sie piuparts nicht nach einem erfolgreichen Build aus. Wenn sbuild für die Ausführung konfiguriert ist
piuparts ist standardmäßig aktiviert. Diese Option verhindert, dass piuparts ausgeführt wird.

--piuparts-opt=Optionen
Führen Sie piuparts mit den angegebenen Optionen aus.

--piuparts-opts=Optionen
Hängen Sie zusätzliche Optionen an vorhandene Optionen an, die an piuparts übergeben wurden.

--piuparts-root-arg=Optionen
Fügen Sie ein Argument hinzu, das zum Starten von piuparts als Root verwendet wird. Wenn es keine Argumente gibt
angegeben, wird piuparts über sudo gestartet.

--piuparts-root-args=Optionen
Fügen Sie Argumente hinzu, die zum Starten von piuparts als Root verwendet werden. Wenn es keine Argumente gibt
angegeben, wird piuparts über sudo gestartet.

--pre-build-commands=Schnur
Dies ist der früheste externe Befehl, der direkt nach der Chroot-Sitzung ausgeführt wird
initialisiert wurde und bevor irgendetwas anderes getan wird (z. B. die Installation des Builds).
Abhängigkeiten). Der Befehl wird als Root außerhalb der Chroot ausgeführt. Diese Option kann sein
Wird mehrmals verwendet, um mehrere Befehle hinzuzufügen. Siehe den Abschnitt EXTERNAL BEFEHLE für
mehr Informationen.

--chroot-setup-commands=Schnur
Führen Sie diese Befehle aus, nachdem Chroot und Variablen eingerichtet wurden, aber vorher
Abhängigkeiten werden installiert. Der Befehl wird als Root innerhalb der Chroot ausgeführt. Das
Die Option kann mehrmals verwendet werden, um mehrere Befehle hinzuzufügen. Siehe den Abschnitt
EXTERNAL BEFEHLE .

--build-deps-failed-commands=Schnur
Diese Befehle werden ausgeführt, wenn die Installation der Build-Abhängigkeiten direkt fehlgeschlagen ist
nach dem gescheiterten Versuch. Die Umgebung ist intakt, und der Fehler kann sein
untersucht. Besonders %SBUILD_SHELL ist hier nützlich. Der Befehl wird als Root ausgeführt
innerhalb der Chroot. Diese Option kann mehrmals verwendet werden, um mehrere Befehle hinzuzufügen.
Siehe den Abschnitt EXTERNAL BEFEHLE .

--starting-build-commands=Schnur
Führen Sie diese Befehle aus, nachdem Abhängigkeiten installiert wurden, unmittelbar vor der Paketerstellung
mit dpkg-buildpackage startet. Der Befehl wird als Benutzer (ohne Rootberechtigung) ausgeführt
innerhalb der Chroot aufbauen. Diese Option kann mehrmals verwendet werden, um mehrere hinzuzufügen
Befehle. Siehe den Abschnitt EXTERNAL BEFEHLE .

--finished-build-commands=Schnur
Führen Sie diese Befehle unmittelbar nach Abschluss der zeitgesteuerten Paketerstellung aus. Der Befehl
wird als (Nicht-Root-)Benutzer ausgeführt, der sbuild innerhalb der Chroot ausführt. Diese Option kann sein
Wird mehrmals verwendet, um mehrere Befehle hinzuzufügen. Siehe den Abschnitt EXTERNAL BEFEHLE für
mehr Informationen.

--build-failed-commands=Schnur
Diese Befehle werden ausgeführt, wenn dpkg-buildpackage direkt nach dem Fehler fehlschlägt
versuchen. Die Umgebung ist intakt und der Fehler kann untersucht werden.
Besonders %SBUILD_SHELL ist hier nützlich. Der Befehl wird als Benutzer (ohne Rootberechtigung) ausgeführt
Ausführen von %sbuild innerhalb der Chroot. Diese Option kann zum Hinzufügen mehrmals verwendet werden
mehrere Befehle. Siehe den Abschnitt EXTERNAL BEFEHLE .

--chroot-cleanup-commands=Schnur
Führen Sie diese Befehle aus, wenn eine Chroot bereinigt wird, bevor das Build-Verzeichnis gelöscht wird.
Der Befehl wird als Root innerhalb der Chroot ausgeführt. Diese Option kann mehrfach verwendet werden
Mal, um mehrere Befehle hinzuzufügen. Siehe den Abschnitt EXTERNAL BEFEHLE Für weitere
Informationen.

--post-build-commands=Schnur
Führen Sie diesen Befehl nach einem erfolgreichen Build aus. Der Befehl wird als Root außerhalb von ausgeführt
die Chroot. Diese Option kann mehrmals verwendet werden, um mehrere Befehle hinzuzufügen. Sehen
die Sektion EXTERNAL BEFEHLE .

--anything-failed-commands=Schnur
Führen Sie diese Befehle für alle aus --xxx-failed-commands Optionen. Besonders
%SBUILD_SHELL ist hier nützlich. Diese Option kann zum Hinzufügen mehrmals verwendet werden
mehrere Befehle. Siehe den Abschnitt EXTERNAL BEFEHLE .

--log-external-command-output
Schreiben Sie die Ausgabe externer Befehle in das Build-Protokoll.

--log-external-command-error
Schreiben Sie die Fehlerausgabe externer Befehle in das Build-Protokoll.

--setup-hook=Hook-Skript DEPARCATED
Diese Option ist veraltet. Die Verwendung dieser Option fügt hinzu Hook-Skript nach außen
Befehle, über die ausgeführt werden soll chroot-setup-commands.

--build-dep-resolver=Resolver
Verwenden Sie den angegebenen Resolver, um die Auswahl der Build-Abhängigkeiten zu übernehmen. Unterstützt
Resolver sind geeignet (der Standard), Eignung, aspcud und xapt. Der passende Resolver ist
Der am besten geeignete Resolver für die meisten Benutzer, zum Erstellen für instabile, stabile und
andere Distributionen. Wenn alternative Build-Abhängigkeiten verwendet werden (ausgenommen
Architektureinschränkungen) wird nur die erste Alternative verwendet; die Anderen
wird ignoriert. Der Aptitude Resolver ist sehr ähnlich, aber intelligenter und langsamer.
und es werden standardmäßig alle Alternativen berücksichtigt; es ist für komplexere geeignet
Situationen, wie zum Beispiel das Erstellen von Paketen für die experimentelle Verteilung, wo
Pakete müssen aus mehreren Suiten installiert werden (instabil und experimentell). Wegen
Aufgrund von Leistungs- und anderen Problemen (Bug #139615) wird die Verwendung von aptitude nicht empfohlen
Standard. Wenn die Abhängigkeitssituation so komplex ist, dass weder apt noch aptitude
Wenn Sie eine Lösung finden, können Sie den Aspcud-Resolver verwenden. Dieser Resolver
verwendet apt-cudf, um aspcud, einen echten SAT-Löser, nach einer Lösung für die Installation zu fragen
Problem. Da aspcud ein echter SAT-Löser ist, wird es immer eine Lösung finden, wenn überhaupt
existiert. Der xapt-Resolver ist nur für Cross-Building gedacht und temporär
Übergangsfunktion, die nach der vollständigen Einführung von entfernt wird
Multi-Arch-Unterstützung.

--resolve-alternatives
Erlauben Sie die Verwendung von Alternativen in Build-Depends, Build-Depends-Arch und Build-
Abhängig-Unabhängig. Dies ist die Standardeinstellung für den Aptitude-Abhängigkeitslöser.

--no-resolve-alternatives
Erlauben Sie nicht die Verwendung von Alternativen in Build-Depends, Build-Depends-Arch und
Build-Depends-Indep. Beachten Sie, dass Alternativen für dasselbe Paket (z. B. verschiedene) möglich sind
Versionen) sind weiterhin zulässig. Dies ist die Standardeinstellung für die apt- und xapt-Abhängigkeit
Resolver.

--extra-package=package.deb
Marke package.deb Verfügbar für die Build-Abhängigkeitsauflösung, indem Sie es zu a hinzufügen
temporäres Archiv, erstellt von sbuild. Dies erleichtert die Erstellung von Paketen
gegen lokal erstellte Build-Abhängigkeiten, ohne auf diese Pakete warten zu müssen
Betreten Sie das Hauptarchiv oder machen Sie sich die Mühe, ein lokales Archiv zu verwalten
und es innerhalb der Chroot zugänglich zu machen. package.deb wird in die Chroot kopiert,
Es kann also auf jeden Pfad auf dem Hostsystem verweisen.

--extra-repository=spec
Fügen Sie während der Paketerstellung ein Repository zur Liste der apt-Quellen hinzu. Der
Die Repository-Spezifikation ist eine Zeile, die für ein Apt geeignet ist sources.list(5) Datei. Für
Beispiel könnten Sie verwenden --extra-repository="deb http://httpredir.debian.org/debian
experimentell hauptsächlich" damit Pakete in der experimentellen Distribution ausgeführt werden können
Build-Abhängigkeiten. Beachten Sie, dass die Build-Chroot diesem Schlüssel bereits vertrauen muss
Repository oder ein Schlüssel muss mit angegeben werden --extra-repository-key Flagge. (sehen geeignet-
Verbindung(8))

--extra-repository-key=Datei.asc
Speichern Datei.asc zur Liste der vertrauenswürdigen Schlüssel innerhalb der Chroot. Der Schlüssel wird ausgelesen
Der angegebene Dateiname wird hinzugefügt und zu den vertrauenswürdigen Schlüsseln hinzugefügt. Weitere Informationen finden Sie unter geeignet-
Verbindung(8). Dieses Flag ist besonders nützlich, wenn das Ziel in --extra-repository is
nicht mit einem Schlüssel signiert, dem die Basis-Chroot vertraut.

--build-path=Schnur
Standardmäßig wird das Paket in einem Pfad mit dem folgenden Format erstellt
/build/packagename-XXXXXX/packagename-version/ wobei XXXXXX ein zufälliges ASCII ist
Zeichenfolge. Mit dieser Option kann ein benutzerdefinierter Pfad angegeben werden, in dem das Paket erstellt wird
innerhalb der Chroot. Beachten Sie, dass der Sbuild-Benutzer in der Chroot über Berechtigungen verfügen muss
um den Weg zu erstellen. Gemeinsame beschreibbare Speicherorte sind Unterverzeichnisse von / Tmp oder /build.
Der Buildpfad muss ein leeres Verzeichnis sein, da er die letzte Komponente des Pfads darstellt
wird nach Abschluss des Builds entfernt. Wenn Sie mehrere Builds ausführen
Stellen Sie sicher, dass Instanzen mit demselben Build-Pfad parallel für dasselbe Paket erstellt werden
Ihr Build-Pfad befindet sich nicht in einem Verzeichnis, das gemeinsam von allen Build-Instanzen gemountet wird
(mögen / Tmp or / Home). Verwenden Sie in diesem Fall beispielsweise /build stattdessen. Ansonsten Ihr
Builds werden wahrscheinlich fehlschlagen oder falsche Inhalte enthalten.

--sbuild-mode=Modus
Verhaltensänderungen für die Verwendung in einer Build-Umgebung. Dies überschreibt die $sbuild_mode
Konfigurationsoption.

EXTERNAL BEFEHLE

Es wird Unterstützung für die Ausführung externer Befehle während eines Sbuild-Laufs bereitgestellt. Eine Reihe von externen
Befehle können in verschiedenen Phasen eines Builds ausgeführt werden. Die Bereitstellung der auszuführenden Befehle ist abgeschlossen
durch die entsprechenden Optionen in der Befehlszeile und durch die Verwendung von
Konfigurationsdateien. In der Konfigurationsdatei wird die Liste der auszuführenden Befehle abgelegt
ein Hash von Arrays von Arrays von Zeichenfolgen, die den auszuführenden Befehlen entsprechen.

Es gibt mehrere Befehlssätze. Der vor/nach dem Bau Befehle werden außerhalb des ausgeführt
chroot. Der chroot-setup/cleanup- Befehle und Start/Fertigbau- Befehle werden ausgeführt
innerhalb der Chroot. Sie werden alle als Root ausgeführt, mit Ausnahme von Baubeginn/-abschluss Befehle,
die als aktueller Build-Benutzer ausgeführt werden. Build-Deps-fehlgeschlagen läuft ähnlich wie
Chroot-Setup: in der Chroot als Root. Build-fehlgeschlagen läuft ähnlich wie fertig gebaut: in dem
chroot als Benutzer.

Hier ist eine Zusammenfassung der Reihenfolge, Benutzer, intern/extern zum Chrooten für jeden Befehls-Hook

Die folgende Tabelle zeigt jeden Befehls-Hook im Kontext der von sbuild ausgeführten Aufgaben.
Die Kolumne Wurzel zeigt an, ob der Befehl als Root ausgeführt wird (Ja) oder nicht (Nein). Die Kolumne
Chroot zeigt an, ob der Befehl innerhalb oder außerhalb der Chroot ausgeführt wird. Der Rest
Die Spalten zeigen die prozentualen Escapezeichen an, die in jedem Befehl definiert sind. Prozent entgeht dem
sind in allen Befehlen verfügbar (%%, %d, %a, %b, %p, %s) entfallen.

Befehl/Aktion root chroot %c %r
──────────────────────────────────────── ────────── ────────────────
Chroot-Sitzung initialisieren
--pre-build-commands ja draußen nein ja
Richten Sie Chroot und Variablen ein
--chroot-setup-commands ja drinnen nein nein
Update- und Upgrade-Pakete
Abhängigkeiten installieren
--build-deps-failed-commands ja drinnen nein nein
--starting-build-commands nein drinnen nein nein
Führen Sie dpkg-buildpackage aus
--build-failed-commands nein drinnen nein nein
--finished-build-commands nein drinnen nein nein
Lintian ausführen (falls konfiguriert)
Bereinigen Sie Builddateien und Abhängigkeiten
--chroot-cleanup-commands ja drinnen ja nein
Schließen Sie die Schroot-Sitzung
Piuparts ausführen (falls konfiguriert)
--post-build-commands ja draußen ja ja

Die Befehle können in den Konfigurationsdateien angegeben werden. Sie können als Strings oder als angegeben werden
Liste der Argumente. Zum Beispiel, um „foo“ und „bar“ mit Argumenten vor einem Build auszuführen
startet und den Befehl „foo“ als Liste und „bar“ als String angibt, könnte man Folgendes tun:

$external_commands = {
„pre-build-commands“ => [
['foo', 'arg1', 'arg2'],
'Bar Arg1 Arg2 arg3',
],
};

Hash-Schlüssel für Befehle, die in anderen Phasen ausgeführt werden sollen, haben denselben Namen wie die entsprechenden
Name der Befehlszeilenoption ohne das vorangehende „--“.

Hier ist ein Beispiel dafür, wie man dasselbe mit dem vorherigen Beispiel macht, außer dass man das verwendet
--pre-build-commands .

$ bauen \
--pre-build-commands='foo Arg1 arg2' \
--pre-build-commands='bar Arg1 Arg2 arg3'

Beachten Sie, dass alle diese Befehle über die Shell in „ ausgeführt werden./ Bin / sh". Falls angegeben
den Befehl als Liste in der Konfigurationsdatei, nur sehr wenige Shell-Funktionen werden unterstützt: nein
Umleitung, keine Befehlsverkettung mit ; und so weiter. Bei der Übergabe einer Zeichenfolge (im
config-Datei oder in der Befehlszeile) wird die Zeichenfolge unverändert an die Shell übergeben. Also alles Shell
Einrichtungen sind vorhanden, vorausgesetzt, dass Sie alles richtig entkommen, wie Sie es in einem tun würden
interaktive Hülle.

Neben der Ausführung externer Befehle kann sbuild auch die Verwendung bestimmter Prozente erkennen
Escapezeichen, die als Argumente angegeben werden. Diese werden verwendet, um die Bereitstellung eines Befehls mit a zu ermöglichen
bestimmtes Argument abhängig von der angegebenen Flucht. Zum Beispiel könnte es möglich sein, zu haben
einem externen Befehl kann der Pfad zu einer .changes-Datei übergeben werden.

Hier finden Sie eine Liste der Schlüsselwörter und eine Beschreibung dessen, in was sie konvertiert werden.

%% Wird verwendet, um einem ' zu entkommen%'.

%d, %SBUILD_DSC
Diese Escapezeichen werden in den absoluten Pfad zur .dsc-Datei eines Pakets konvertiert.

%c, %SBUILD_CHANGES
Diese Escapezeichen werden in den absoluten Pfad zu den Quell-.changes eines Pakets konvertiert
Datei. Diese Variable wird erst gesetzt, nachdem der Build abgeschlossen ist, also in
--chroot-cleanup-commands und --post-build-commands.

%a, %SBUILD_HOST_ARCH
Diese Escapezeichen werden in den Debian-Namen der Architektur konvertiert, um die es sich handelt
wird gebaut für (z. B. amd64, armhf).

%r, %SBUILD_CHROOT_DIR
Diese Escapezeichen werden in den absoluten Pfad auf dem Host zum Stammverzeichnis konvertiert
der Chroot. Diese Variable wird nicht gesetzt, wenn der externe Befehl innerhalb von ausgeführt wird
chroot. Daher ist diese Flucht nur für verfügbar --pre-build-commands und
--post-build-commands.

%b, %SBUILD_BUILD_DIR
Diese Escapezeichen werden in den absoluten Pfad zum Build-Verzeichnis innerhalb des konvertiert
chroot.

%p, %SBUILD_PKGBUILD_DIR
Diese Escapezeichen werden in den absoluten Pfad zum Paketerstellungsverzeichnis konvertiert
innerhalb der Chroot.

%s, %SBUILD_SHELL
Dies wird in einen Befehl umgewandelt, um eine interaktive „Bash“-Shell zu erzeugen

Prozent-Escapezeichen werden nur ersetzt, wenn ein geeigneter Wert für sie definiert ist. Bei
In anderen Fällen bleibt es unverändert. In der Praxis bedeutet dies, dass es nur zwei Fluchtwege gibt
die nicht in allen externen Befehlen verfügbar sind: %c und %r. Zum Beispiel eine .changes-Datei
wird erst am Ende eines Builds definiert, also mit %c wird nur nachträglich ersetzt
Build-Befehle.

Hier ist ein Beispiel für die Verwendung eines Escapes, um nach einem Build ein Programm foo für eine .changes-Datei auszuführen
erledigt.

$ bauen --post-build-commands \
'foo %SBUILD_CHANGES'

Und hier ist ein Beispiel, das eine interaktive Shell zur Untersuchung des Problems erzeugt
wann immer der Build fehlgeschlagen ist:

$ bauen --build-failed-commands '%S'

Ein letzter Hinweis: Externe Befehle werden in der Reihenfolge verarbeitet, in der sie gegeben werden. Auch der
Zuerst werden die in einer Konfigurationsdatei angegebenen Befehle verarbeitet, dann die angegebenen Befehle
über die Befehlszeilenoptionen.

LOCAL ARCHIV

Die Resolver apt und aptitude erstellen ein lokales Archiv für die Installation von Build-Abhängigkeiten.
Dies ist ein internes Implementierungsdetail des Build-Abhängigkeits-Resolvers, was nicht der Fall ist
Vom Benutzer konfigurierbar und soll für den Benutzer völlig transparent sein. Die lokale
Das Archiv existiert nur vorübergehend während der Paketerstellung. Es bleibt nicht bestehen
Builds, und es wird nur zum Speichern der Dummy-Abhängigkeitspakete verwendet, die für einen einzelnen erstellt wurden
bauen.

Die Abhängigkeitslöser führen Folgendes aus:

· Erstellen Sie ein Dummy-Abhängigkeitspaket. Dies enthält die Build-Depends (und optional
Build-Depends-Arch und Build-Depends-Indep) als Depends und Build-Conflicts (und
optional Build-Conflicts-Arch und Build-Conflicts-Indep) als Konflikte.

· Installieren Sie das Dummy-Abhängigkeitspaket im lokalen Archiv.

· Generieren Sie die Angebote, Quellen und Loslassen Dateien.

· Schreib ein sources.list Datei für das lokale Archiv in /etc/apt/sources.list.d.

· Fügen Sie die Listen direkt ein /var/lib/apt/lists. Dieser Schritt dient dazu, das Laufen zu sparen
Aktualisieren aller Apt-Quellen, was während eines Builds unerwünscht ist; apt und aptitude do
Derzeit wird die Aktualisierung einer einzelnen Quelle nicht unterstützt.

· Generieren Sie die Apt-Caches neu, um sicherzustellen, dass alles synchron ist.

· Installieren Sie das Dummy-Abhängigkeitspaket mit apt oder aptitude; das Dummy-Paket ist
aus dem lokalen apt-Archiv gezogen, während alle seine Abhängigkeiten aus dem gezogen werden
Regelmäßig konfigurierte Apt-Quellen.

Am Ende des Builds wird das lokale Archiv zusammen mit dem Rest des Builds entfernt
Baum.

VARIABLEN

Die folgenden Umgebungsvariablen werden verwendet von bauen:

HOME Das Home-Verzeichnis des Benutzers.

LOGNAME
Wird in Sperrdateien verwendet.

SBUILD_CONFIG
Pfad zu einer zusätzlichen Konfigurationsdatei zusätzlich zur systemweiten und benutzerspezifischen Datei
konkrete.

Verwenden Sie sbuild online mit den onworks.net-Diensten