Verwenden von Devtools unter Arch Linux

• Kompilieren mit Devtools
• Devtools-Konfigurationsdateien
• Lokales Repository
• Paket schneller

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 baseund 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-develund 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 PKGBUILDfalsch 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.

Kompilieren mit Devtools

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 PKGBUILDaus 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 baseund 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 PKGBUILDDateien 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 namcapAusgabe aufmerksam zu machen , es sei denn, Sie haben es geprüft und überprüft, ob eine Änderung vorgenommen werden sollte.

Sie können pacmandas 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-buildjetzt 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-buildläuft makechrootpkg, was intern aufruft makepkg. extra-x86_64-buildFolgende 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-buildnachher --werden an übergeben makechrootpkg, wenn es intern verwendet wird. Mehrere Argumente werden immer automatisch von extra-x86_64-buildan ü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 makechrootpkgan, die Build-Chroot zu entfernen und eine neue Kopie der Clean-Chroot zu namcaperstellen und das Paket auszuführen , wenn es erfolgreich erstellt wurde. Eine häufig verwendete Option, an die übergeben werden kann, makechrootpkgist -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 makechrootpkgnach --werden weitergegeben makepkg, wenn es intern verwendet er das Paket zu erstellen. Das erste Mal makepkgausgefü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 makepkgein zweites Mal um das Paket zu bauen, und immer automatisch übergibt makepkgArgumente von --syncdeps --noconfirm --log --holdver --skipintegdenen sagen makepkgzu, 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/archbuilddies 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-buildWenn 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.

Devtools-Konfigurationsdateien

Bei Devtools-Konfigurationsdateien sind einige Besonderheiten zu beachten. Sie befinden sich in /usr/share/devtools/wie makepkg-x86_64.confund pacman-extra.conf:

• Bei /etcDateien wie makepkg.confund pacman.confkö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,, PACKAGERund {SRC,SRCPKG,PKG,LOG}DESTwird /etc/makepkg.confeher 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 pacmanAusfü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.confund fügen Sie am Ende Folgendes hinzu:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Bearbeiten Sie /etc/pacman.confund 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-buildverwenden:

$ 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/devtoolsZum 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.xzein einzelner Thread für die xzKomprimierung verwendet.

Auf Systemen mit mehreren CPUs können Sie die xzVerwendung mehrerer Threads durch Bearbeiten zulassen /usr/share/devtools/makepkg-x86_64.confund 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.confund ändern Sie die folgende Zeile:

PKGEXT='.pkg.tar.xz'

Ändern Sie es so, dass es wie folgt aussieht:

PKGEXT='.pkg.tar'