Das Paket Devtools wurde ursprünglich für vertrauenswürdige Benutzer erstellt, um Pakete für die offiziellen Repositorys ordnungsgemäß zu erstellen. Es kann jedoch auch von normalen Benutzern verwendet werden, um AUR-Pakete oder sogar modifizierte offizielle Pakete zu erstellen.
In diesem Handbuch finden Sie Informationen zum Verständnis und zur Verwendung des AUR im Allgemeinen, einschließlich des Erhaltens des PKGBUILD
. In diesem Dokument werden nur die für Devtools spezifischen Schritte angezeigt, wenn Sie diese Methode zum Kompilieren eines Pakets auswählen.
Devtools verwaltet eine separate saubere Arch-Installation in /var/lib/archbuild/<TARGET>/root
, die nur Paketgruppen base
und enthält base-devel
. Wenn diese Neuinstallation nicht vorhanden ist, wird sie automatisch erstellt. Wenn es vorhanden ist, werden alle darin enthaltenen Pakete automatisch aktualisiert. Wenn Devtools zum Erstellen eines Pakets verwendet wird, beginnt es mit einer Kopie dieser Neuinstallation, installiert die erforderlichen Pakete nur in die Kopie, kopiert den Quellcode hinein, führt das Kompilieren und Packen darin durch und kopiert nur das resultierende Paket. in identischer Form wie in den offiziellen Repositories.
Devtools bietet Vorteile gegenüber dem direkten Ausführen makepkg
. Ein Vorteil ist, dass base-devel
und andere Pakete, die zum Kompilieren, aber nicht zum Ausführen des Pakets erforderlich sind, niemals in Ihrem Hauptsystem landen. Das sind weniger Pakete, die regelmäßig aktualisiert werden müssen und Bedenken haben. Obwohl dies in erster Linie ein Vorteil für Arch-Paketbetreuer ist, kann dieser Prozess leicht aufdecken, wenn a PKGBUILD
falsch ist, z. B. wenn eine Abhängigkeit von der Auflistung übersehen wird, die der Betreuer zufällig bereits in seinem Hauptsystem installiert hat. Sie können auch eine Maschine verwenden, die Pakete schneller erstellt, und das resultierende Paket auf eine langsamere Maschine kopieren, auf der es ausgeführt wird, ohne die Installation der Baumaschine zu verschmutzen.
Der Hauptnachteil besteht darin, dass die saubere Wurzel immer vorhanden ist und etwa 800 MB benötigt. In der Regel nimmt eine einzelne Kopie mehr Speicherplatz in Anspruch. Beachten Sie, dass bei /var/lib/archbuild/
Verwendung von Btrfs die Kopie des sauberen Stamms zunächst ein Btrfs-Snapshot ist, sodass diese Dateien nicht doppelt so viel Speicherplatz beanspruchen. Das saubere Stammverzeichnis wird immer dort aufbewahrt, um zu vermeiden, dass es jedes Mal neu installiert wird, wenn ein Paket erstellt wird.
Installieren Sie Devtools:
# pacman -S devtools
Um ein Paket zu erstellen, enthält Devtools archbuild
, aber Sie führen dies nicht direkt aus. Es enthält auch Symlinks von {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build
. Der Symlink, der zum Ausführen verwendet wird, wird überprüft archbuild
, um festzustellen, welches Ziel verwendet werden soll. Es kann ausgeführt werden, um diese instabilen / Staging / Test-Repositorys zu verwenden, die möglicherweise neuere Versionen haben, als für die offiziellen Repositorys freigegeben wurden. Führen Sie Folgendes PKGBUILD
aus git clone
, um die offiziellen Repositorys für Nicht-AUR-Pakete in dem Verzeichnis mit dem beispielsweise von erstellten Verzeichnis zu verwenden :
$ extra-x86_64-build
Hinweis: Der Rest dieses Handbuchs bezieht sich lediglich auf extra-x86_64-build
.
Nach Abschluss der Ausführung werden folgende Ergebnisse angezeigt:
/var/lib/archbuild/extra-x86_64/root
- Eine saubere Chroot , eine aktuelle Installation mit nur Paketgruppen base
und base-devel
.
/var/lib/archbuild/extra-x86_64/<USERNAME>
- Dies wird eine Build-Chroot enthalten . Dies ist eine Kopie der sauberen Chroot mit allen Abhängigkeiten, die zum Erstellen oder Ausführen des zu erstellenden Pakets erforderlich sind, sowie dessen Quellcode, Kompilierungsergebnisse und Paket.
- Das Verzeichnis, in dem Sie sich befinden, enthält das Paket und die Build-Protokolldateien sowie den heruntergeladenen Quellcode.
Am Ende werden Sie möglicherweise " Checking PKGBUILD
" und " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz
" bemerken . Alle Zeilen danach werden ausgegeben namcap
, die automatisch nach Problemen wie fehlerhaften PKGBUILD
Dateien suchen , Abhängigkeiten, die das Paket scheinbar nicht verwendet, Abhängigkeiten, die das Paket scheinbar nicht verwendet, und vieles mehr. False Positives werden oft von generiert namcap
, sind aber ein großartiges Werkzeug, um Nachforschungen anzustellen. Wenn Ihr Paket ordnungsgemäß funktioniert, ist es keine gute Idee, den Betreuer auf die namcap
Ausgabe aufmerksam zu machen , es sei denn, Sie haben es geprüft und überprüft, ob eine Änderung vorgenommen werden sollte.
Sie können pacman
das Paket installieren, wodurch alle Abhängigkeiten installiert werden, die zum Ausführen des Pakets erforderlich sind, solange sie sich in offiziellen Repositorys oder einem lokalen Repository befinden.
Verwenden Sie entweder ein lokales Repository wie hier beschrieben oder installieren Sie die Datei direkt:
# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz
Wenn Sie extra-x86_64-build
jetzt oder später mit diesem oder einem anderen Paket erneut ausgeführt werden, wird die saubere Chroot bei Bedarf aktualisiert, die Build-Chroot gelöscht und eine neue Kopie der sauberen Chroot erstellt, und der gleiche Vorgang wird ausgeführt. Wenn in Ihrem Verzeichnis der Quellcode vom letzten Mal noch heruntergeladen wurde, wird er verwendet. Wenn es sich bei dem Paket um ein AUR-Entwicklungspaket handelt, werden neue Änderungen vorgenommen, anstatt erneut geklont zu werden.
Intern extra-x86_64-build
läuft makechrootpkg
, was intern aufruft makepkg
. extra-x86_64-build
Folgende Optionen stehen zur Verfügung:
-c
: Bereinigen Sie die Chroots, indem Sie das gesamte /var/lib/archbuild/extra-x86_64/
Verzeichnis entfernen und neu erstellen, einschließlich der Clean-Chroot und aller Build-Chroot-Verzeichnisse. Dies wird selten benötigt, nur wenn die saubere Chroot beschädigt wird oder wenn Devtools so aktualisiert wird, dass die Abwärtskompatibilität beeinträchtigt wird.
-r <dir>
: Verwenden Sie ein anderes Verzeichnis als /var/lib/archbuild/extra-x86_64/
die Chroots.
Alle Argumente extra-x86_64-build
nachher --
werden an übergeben makechrootpkg
, wenn es intern verwendet wird. Mehrere Argumente werden immer automatisch von extra-x86_64-build
an übergeben makechrootpkg
. Diese automatischen Argumente sind -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n
. Sie weisen makechrootpkg
an, die Build-Chroot zu entfernen und eine neue Kopie der Clean-Chroot zu namcap
erstellen und das Paket auszuführen , wenn es erfolgreich erstellt wurde. Eine häufig verwendete Option, an die übergeben werden kann, makechrootpkg
ist -l <copy name>
. Dies ist der Verzeichnisname, der anstelle der Build-Chroot angegeben wird. Dies ist <USERNAME>
nützlich, um mehrere Kopien zu verwalten oder mehrere Pakete gleichzeitig zu kompilieren.
Alle Argumente zu makechrootpkg
nach --
werden weitergegeben makepkg
, wenn es intern verwendet er das Paket zu erstellen. Das erste Mal makepkg
ausgeführt wird durch makechrootpkg
, wird es mit seinen eigenen unveränderbaren Optionen getan, um Download - Quelldateien, falls erforderlich, und führen Sie Integritätsprüfungen; somit kann bei diesem Lauf nichts weitergeleitet werden. Es läuft makepkg
ein zweites Mal um das Paket zu bauen, und immer automatisch übergibt makepkg
Argumente von --syncdeps --noconfirm --log --holdver --skipinteg
denen sagen makepkg
zu, innerhalb des Build - chroot, installieren Sie automatisch Abhängigkeiten erforderlich für den Aufbau und die Verwendung des Pakets fehlen, während für die Bestätigung zu fragen pacman
, melden Sie den Build - Prozess zu Text Dateien zusätzlich stdout
, aktualisieren Sie den Quellcode nicht, wenn Sie sich in einem Versionskontrollsystem befinden, und führen Sie keine Überprüfungen der Quelldatei durch.
Sie können diese mithilfe des folgenden Formulars miteinander verketten:
$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>
Beachten Sie, dass /var/lib/archbuild
dies so behandelt werden kann, als wäre es ein temporäres Verzeichnis. Wenn Sie mehrere Vultr-Festplatten haben, lohnt es sich, hier ein RAID0-Dateisystem (Stripe) einzubinden. Wenn Sie viel RAM haben, können Sie auch ein RAM-gestütztes Dateisystem wie mounten tmpfs
. Nachdem ein Paket erstellt wurde, wird es in das Verzeichnis kopiert, aus dem Sie ausgeführt wurden. extra-x86_64-build
Wenn Sie möchten, können Sie es an dieser Stelle löschen /var/lib/archbuild
. Der nächste Lauf wäre langsamer, da eine neue saubere Wurzel erstellt werden müsste. Alternativ können Sie löschen /var/lib/archbuild/<USERNAME>
, um zusätzlichen Speicherplatz aus dem Build-Chroot zurückzugewinnen, bevor dieser bei der nächsten Ausführung von Devtools automatisch gelöscht wird. Selbst wenn ein hier gemountetes RAID0-Dateisystem ausfallen würde, würden Sie höchstens eine laufende Kompilierung verlieren.
Bei Devtools-Konfigurationsdateien sind einige Besonderheiten zu beachten. Sie befinden sich in /usr/share/devtools/
wie makepkg-x86_64.conf
und pacman-extra.conf
:
- Bei
/etc
Dateien wie makepkg.conf
und pacman.conf
können Sie diese sicher an Ort und Stelle bearbeiten. Wenn das Paket aktualisiert wird, werden Ihre Änderungen nicht überschrieben. Vielmehr werden die neuen Konfigurationsdateien (sofern sie sich gegenüber der vorherigen Version geändert haben) gespeichert, die mit enden .pacnew
. Devtools-Konfigurationsdateien sind /usr/share/
jedoch nicht für die Bearbeitung durch den Benutzer vorgesehen. Wenn Devtools aktualisiert wird, werden Ihre Änderungen an diesen Dateien vollständig überschrieben, ohne dass Sie benachrichtigt werden. Eine Änderung dieses Verhaltens wurde vorgeschlagen und abgelehnt, da dadurch sichergestellt wird, dass Pakete mit denselben Kompilierungseinstellungen an die offiziellen Repositorys gesendet werden.
- Der Wert für
MAKEFLAGS
,, PACKAGER
und {SRC,SRCPKG,PKG,LOG}DEST
wird /etc/makepkg.conf
eher von als genommen /usr/share/devtools/makepkg-x86_64.conf
.
Lokales Repository
Wenn Sie Pakete erstellen, die Abhängigkeiten von anderen von Ihnen erstellten Paketen aufweisen, müssen Sie ein lokales Repository verwenden, damit beim pacman
Ausführen innerhalb der Build-Chroot die Abhängigkeiten gefunden werden.
Informationen zum Einrichten eines lokalen Repositorys finden Sie im Abschnitt "Lokales Repository" dieses Handbuchs .
Erstellen Sie ein benutzerdefiniertes Ziel:
# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf
Bearbeiten Sie /usr/share/devtools/pacman-custom.conf
und fügen Sie am Ende Folgendes hinzu:
[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo
Bearbeiten Sie /etc/pacman.conf
und fügen Sie Folgendes hinzu. Dies erzwingt das Binden des Verzeichnisses in der Chroot:
CacheDir = /var/cache/pacman/pkg/ /archLocalRepo/
Verwenden Sie jetzt Folgendes, anstatt Folgendes zu extra-x86_64-build
verwenden:
$ custom-x86_64-build
Wenn Sie das benutzerdefinierte Ziel immer verwenden möchten, können Sie das /var/lib/archbuild/extra-x86_64-build/
Verzeichnis löschen, falls vorhanden, da sich die Chroots jetzt in befinden /var/lib/archbuild/custom-x86_64-build/
.
Paket schneller
Hinweis: /usr/share/devtools
Zum Aktivieren von Thread-Paketen müssen die Konfigurationsdateien bearbeitet werden, was nicht offiziell unterstützt wird. Daher müssen Sie diese Änderung bei jedem Upgrade von Devtools vornehmen.
Devtools kombiniert ein gesamtes Paket in einem Archivformat. Standardmäßig wird .tar.xz
ein einzelner Thread für die xz
Komprimierung verwendet.
Auf Systemen mit mehreren CPUs können Sie die xz
Verwendung mehrerer Threads durch Bearbeiten zulassen /usr/share/devtools/makepkg-x86_64.conf
und die folgende Zeile ändern:
COMPRESSXZ=(xz -c -z -)
So lassen Sie so viele Threads zu, wie Sie über virtuelle Kerne verfügen:
COMPRESSXZ=(xz -c -z - --threads=0)
Fügen Sie eine bestimmte Anzahl hinzu, um die Verwendung mehrerer virtueller Kerne zu ermöglichen, jedoch nicht aller, um die Auswirkungen auf die Gesamtsystemleistung zu verringern:
COMPRESSXZ=(xz -c -z - --threads=21)
Wenn Sie mehr Threads als die Anzahl der virtuellen Kerne angeben, wird die Leistung verringert.
Wenn es Ihnen nichts ausmacht, dass die Paketdatei (möglicherweise viel) größer ist, deaktivieren Sie die Komprimierung durch Bearbeiten /usr/share/devtools/makepkg-x86_64.conf
und ändern Sie die folgende Zeile:
PKGEXT='.pkg.tar.xz'
Ändern Sie es so, dass es wie folgt aussieht:
PKGEXT='.pkg.tar'