Erstellen von Paketen unter Arch Linux (einschließlich AUR)

• PKGBUILD
• PKGBUILD / ETC erhalten
• Aktualisieren von PKGBUILD / ETC
• Kompilieren
• Lokales Repository
• Schneller kompilieren
• PGP-Signaturfehler
• AUR-Entwicklungspakete
• Veraltete Pakete

Unter Arch Linux sind die offiziellen Repositorys: Core, Extra und Community. Diese Pakete sind bereits kompiliert und werden über installiert pacman. In den meisten Fällen können allgemeine Benutzer ignorieren, dass diese drei offiziellen Repositorys getrennt sind. Core enthält die wichtigsten Pakete wie Kernel, Startvorgang, Netzwerk, Paketverwaltung, openssh usw. Es gibt auch strengere Anforderungen an gründlichere Tests, bevor neue Versionen veröffentlicht werden. Extra enthält andere beliebte Pakete, die nicht so kritisch sind, wie z. B. einen X-Server, Fenstermanager oder Webbrowser. Community enthält weniger beliebte Pakete. Nur vertrauenswürdige Benutzer (ungefähr 60 aktive Benutzer, über die von anderen vertrauenswürdigen Benutzern abgestimmt wurde) haben Zugriff auf Änderungen an den offiziellen Repositorys.

Im Jahr 2019 befinden sich etwa 11.000 Pakete in den offiziellen Repositories unter https://www.archlinux.org/packages . Es gibt jedoch viele andere Programme unter Linux. Das AUR (Arch Linux User Repository) ist also vorhanden, sodass jeder Arch-Benutzer ein neues Programm hinzufügen und dessen Betreuer werden oder ein "verwaistes" Paket ohne einen aktuellen Betreuer übernehmen kann. Es gibt ungefähr 55.000 Pakete in der AUR unter https://aur.archlinux.org/ .

Es gibt 3 kritische Unterschiede zum AUR:

1. Auch diese Pakete können von jedem Benutzer hergestellt werden, auch von einem brandneuen.
2. Die AUR enthält nur PKGBUILDein Shell-Skript zum automatischen Erstellen des Pakets, keine kompilierten Binärdateien. (Manchmal enthält es auch kleine Text-Patches oder Shell-Skripte zum Installieren / Aktualisieren / Deinstallieren). Dies hat eine enorme Arbeit geleistet, die es jedem Benutzer ermöglicht, einen Beitrag zu leisten, und gleichzeitig die Wahrscheinlichkeit verringert, dass jemand in der Lage ist, bösartigen Code zu verbreiten. Die Arch-Community ist immer noch sehr hilfreich bei Problemen mit AUR-Paketen, es wird jedoch darauf hingewiesen, dass die Verwendung dieser Pakete auf eigenes Risiko erfolgt. Da alles, was es bietet, ein ist PKGBUILD, liegt es letztendlich in Ihrer Verantwortung, ein zu überprüfen, das PKGBUILDSie verwenden werden. (Zugegeben, viele Benutzer tun dies nicht und verlassen sich nur darauf, dass andere Wache halten.)
3. Da pacmandie AUR nicht direkt mit der AUR interagiert, liegt es in Ihrer Verantwortung, die AUR-Pakete zu aktualisieren. Wenn Sie Ihr gesamtes System regelmäßig aktualisieren pacman, werden Updates für AUR- PKGBUILDDateien nicht automatisch heruntergeladen , kompiliert und für Sie installiert.

Obwohl sich dieser Artikel auf das Erstellen von Paketen aus dem AUR konzentriert, können dieselben Techniken verwendet werden, um Pakete aus den offiziellen Repositorys selbst zu erstellen.

PKGBUILD

Im Vergleich zu einer .specDatei, die viele andere Distributionen verwenden, PKGBUILDist a ein kurzes und einfaches Shell-Skript. Obwohl einige Pakete komplexer sind, können sie einfach den folgenden ähnlich sein:

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

Dieses Dokument bezieht sich auf:

• PKGNAME: Der Name eines Pakets
• PKGVER: Die Version eines Pakets (entspricht fast immer der Versionsnummer des Upstreams)
• PKGREL: Die Arch "Version" der PKGBUILDfür eine bestimmte PKGVER(normalerweise 1, aber erhöht, wenn Änderungen an einer PKGBUILDzwischen Upstream-Releases vorgenommen werden müssen)
• ARCH: Die Architekturen, auf denen das Paket aufbauen kann (etwas älter, da die offiziellen Arch Linux-Repositorys nur "x86_64" (64-Bit-CPUs) unterstützen, AUR-Pakete jedoch weiterhin "i686" (32-Bit-CPUs) oder "any" unterstützen können Architektur zu bezeichnen ist irrelevant)
• PKGBUILD/ETC: Alle Dateien, die sich tatsächlich im AUR-Repository befinden. die PKGBUILDund alle anderen kleinen Text-Patches oder Shell-Skripte installieren / aktualisieren / deinstallieren. Enthält keine Upstream-Dateien im sourceArray.

Obwohl sich die AUR als äußerst vertrauenswürdig erwiesen hat, ist es eine gute Idee, sich eine anzuschauen PKGBUILD/ETC, um sicherzustellen, dass sie die Quelle von einem Ort bezieht, dem Sie vertrauen möchten. (zum Beispiel ein offizieller Upstream-Standort, der von Github stammen kann - aber nicht nur das Github-Repository einer zufälligen Person, das nicht mit dem Upstream-Paket zusammenhängt); und dass der PKGBUILD/ETCkeinen verdächtigen Code enthält.

Erhalten PKGBUILD/ETC

Von der AUR

Wenn die offiziellen Repositorys kein Paket enthalten, das Sie installieren möchten, suchen Sie unter https://aur.archlinux.org/ danach . Hoffentlich werden Sie feststellen, dass das, was Sie suchen, existiert, aktuell ist und gepflegt wird.

Der beste Weg, um das PKGBUILD/ETCvon der AUR zu erhalten, besteht darin, es über zu klonen git.

Installieren git, falls noch nicht geschehen:

# pacman -S git

Verwenden Sie für dieses Paket die auf der AUR-Website angezeigte "Git Clone URL":

$ git clone https://aur.archlinux.org/fslint.git

Geben Sie das Verzeichnis ein und sehen Sie sich dessen Inhalt an. (Alles, was hier aufgelistet ist, außer . .. .gitdem PKGBUILD/ETC):

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

Wenn Sie dies untersuchen PKGBUILD, werden Sie hoffentlich feststellen, dass es den offiziellen Upstream-Quellcode verwendet und typische Schritte zum Erstellen eines Pakets ausführt, sodass es vertrauenswürdig erscheint. Das .SRCINFOenthält nur die auf der Website angezeigten Informationen über das Paket, ist also nicht besorgniserregend. Wenn es hier andere Dateien gibt, werden diese nicht (direkt) von Upstream bereitgestellt. Daher sollten die Dateien und ihre Verwendung in der Datei PKGBUILDüberprüft werden, um sicherzustellen, dass sie nichts Verdächtiges enthalten.

Aus offiziellen Repositories

Obwohl dies viel seltener erforderlich ist, können Sie ein Paket erstellen, das sich bereits in den offiziellen Repositorys befindet, um einen neuen Patch einzuschließen, eine neuere Version zu erstellen usw.

Beziehen Sie PKGBUILD/ETCaus dem Kern und zusätzlichen Repositories:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

Aus dem Community-Repository:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

Upgrade durchführen PKGBUILD/ETC

Wenn ein Upgrade PKGBUILD/ETCveröffentlicht wird, können Sie in dieses Verzeichnis zurückkehren git cloneund es aktualisieren:

$ git pull

Kompilieren und aktualisieren Sie das Paket anschließend mit der unten angegebenen Methode Ihrer Wahl.

Kompilieren

Es gibt viele Möglichkeiten, Pakete zu kompilieren. Letztendlich nutzt alles makepkg. Es gibt zwei offiziell unterstützte Möglichkeiten:

• Informationen zur direkten Verwendung makepkgfinden Sie unter https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Informationen zur indirekten Verwendung makepkgin einem Clean chrootfinden Sie unter https://www.vultr.com/docs/using-devtools-on-arch-linux .

Es gibt viele AUR Hilfsprogramme, (wie der makepkgWrapper), die von Arch nicht offiziell unterstützt werden, wie zum Beispiel aurutils, yayund die vor kurzem aufgegebenes aurmanund yaourt. Selbst wenn Sie eines dieser anderen Hilfsprogramme verwenden, wird dringend empfohlen, sich mit den offiziell unterstützten Methoden vertraut zu machen, um effektiver zu sein, wenn etwas schief geht.

Der Rest dieses Dokuments bezeichnet die von Ihnen YOUR BUILDERgewählte Methode.

Lokales Repository

Sie können ein lokales Repository als zentralen Speicherort für alle von Ihnen erstellten Pakete einrichten.

Platzieren Sie das lokale Repository an einer beliebigen Stelle:

# mkdir /archLocalRepo

Führen Sie es YOUR BUILDERohne automatische Installationsoptionen aus und kopieren Sie das Paket in Ihr lokales Repository.

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

Fügen Sie das neue Paket zum Repository-Index hinzu:

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

So entfernen Sie ein Paket aus dem Index des Repositorys und der Paketdatei selbst:

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

Wenn Sie eine vorhandene Paketdatei ersetzen müssen, müssen Sie die zu ersetzende Datei separat entfernen und dann die neue hinzufügen. Sie können die neue Datei nicht einfach über die alte kopieren.

Konfigurieren Sie pacmandie Verwendung Ihres lokalen Repositorys durch Bearbeiten /etc/pacman.confund fügen Sie am Ende Folgendes hinzu:

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

Sie müssen pacmandas Wissen über Repository-Datenbanken (einschließlich Ihrer lokalen) aktualisieren. um Pakete anzuzeigen, die Sie hinzugefügt haben:

# pacman -Sy

Sie können das Paket dann installieren, nicht anders als in einem offiziellen Repository:

# pacman -S <PKGNAME>

Hinweis: Wenn das Paket lediglich eine Abhängigkeit von einem anderen Paket ist, das Sie installieren möchten, müssen Sie es nicht direkt installieren. Wenn Sie dieses andere Paket pacmaninstallieren, werden die Abhängigkeitspakete automatisch in Ihrem lokalen Repository gefunden und installiert.

Schneller kompilieren

Standardmäßig wird YOUR BUILDERmit einem einzelnen Thread kompiliert. Auf Systemen mit mehreren CPUs können Sie nach Möglichkeit die Verwendung mehrerer Threads zulassen. Das Build-System kompiliert Teile des Quellcodes parallel, wenn dies möglich ist. Manchmal erfordern Teile des Codes, dass andere Teile, mit denen es interagiert, bereits kompiliert sind, sodass nicht immer so viele Threads verwendet werden, wie zulässig sind. Bearbeiten /etc/makepkg.conf.

Fügen Sie Folgendes hinzu, um die Verwendung so vieler Threads zu ermöglichen, wie Sie über virtuelle Kerne verfügen:

MAKEFLAGS="-j$(nproc)"

Hinweis: Dadurch wird der Befehl nprocjedes Mal ausgeführt, sodass immer die aktuelle Anzahl von Kernen verwendet wird, falls Sie Ihren Vultr-Server aktualisieren

Fügen Sie eine bestimmte Anzahl hinzu, um die Verwendung mehrerer, aber nicht aller virtuellen Kerne zu ermöglichen, z. B. um die Auswirkungen auf die Gesamtsystemleistung zu verringern. Wenn Sie beispielsweise 24 Kerne haben, können Sie die Verwendung von 21 zulassen:

MAKEFLAGS="-j21"

Wenn Sie mehr Threads als die Anzahl der virtuellen Kerne angeben, wird die Leistung verringert.

Es ist ziemlich selten, aber die Build-Systeme einiger Pakete haben Probleme mit der parallelen Kompilierung, da Abhängigkeiten zwischen Codeteilen nicht richtig definiert werden. In der Regel werden die PKGBUILDDateien dieser Pakete dies durch Aufrufen für Sie erledigen make -j1, wodurch der von Ihnen festgelegte Standard überschrieben wird. Wenn es dies benötigt und es fehlt, melden Sie es dem Arch-Paketbetreuer.

PGP-Signaturfehler

Ein PKGBUILDQuellarray kann .ascoder .sigDateien enthalten . Sie werden häufig mit einer Bash-Brace-Erweiterung geliefert und sind daher leicht zu übersehen:

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

Wenn eines dieser Formate von Signaturdateien im Quellarray enthalten ist, wird YOUR BUILDERautomatisch versucht, die Signatur des Upstream-Quellarchivs zu überprüfen. Der PGP-Schlüssel der Signatur muss sich im Schlüsselbund des Benutzers befinden. Andernfalls wird der Fehler abgebrochen:

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

Es ist wichtig zu verstehen, dass ein GPG-Schlüssel auf verschiedene Arten angezeigt werden kann. Der Fingerabdruck besteht aus 40 hexadezimalen Zeichen und sollte immer verwendet werden. Eine lange Schlüssel-ID besteht aus den letzten 16 Ziffern und eine kurze Schlüssel-ID aus den letzten 8 Ziffern. Obwohl kürzer praktisch ist, können Duplikate verwendet werden, wodurch die gesamte Begründung für die Überprüfung von Signaturen ungültig wird. Schlimmer noch, es ist bekannt, dass Angreifer gefälschte Schlüssel generieren, die Schlüsseln mit geringerer Länge für hochkarätige Entwickler entsprechen.

Erhalten und überprüfen Sie den Fingerabdruck des PGP-Schlüssels

Wenn Sie das Paket noch nicht erstellt haben, laden Sie die Quellen herunter, die die Signaturdatei enthalten: (Wenn Sie versucht haben, das Paket zu erstellen, ist es bereits vorhanden.)

$ makepkg --nobuild --noextract

So erhalten Sie den vollständigen Fingerabdruck:

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

Idealerweise sollten Sie diesen Fingerabdruck von oben überprüfen. Um sicher zu gehen, sollte Upstream die Schlüssel seiner Betreuer irgendwo auf seiner Website oder in der Quelle angeben. Das bloße Suchen nach dem Schlüssel auf einem Schlüsselserver macht eigentlich nichts. Ein Angreifer kann leicht einen gefälschten Schlüssel senden, da Schlüsselserver die Authentizität nicht überprüfen. Schlüssel können mit anderen Schlüsseln signiert werden. Wenn Sie also bereits einen Schlüssel haben, dem Sie vertrauen, sollten Sie ziemlich sicher sein, wenn Sie den von ihnen signierten Schlüsseln vertrauen.

Das kann eine Menge Arbeit sein, insbesondere wenn Upstream seinen Fingerabdruck nicht veröffentlicht oder an einem leicht zu findenden Ort platziert. Das PKGBUILDenthält ein validpgpkeysArray, das vom Arch-Betreuer hinzugefügt wurde. Wenn es sich bei dem Paket um ein offizielles Repository handelt, bedeutet dies, dass ein vertrauenswürdiger Benutzer es dort abgelegt hat, und Sie sollten ziemlich sicher sein, nur den im Array aufgeführten Elementen zu vertrauen. Wenn sich das Paket in der AUR befindet, bedeutet dies nur, dass ein anderer Arch-Benutzer es dort abgelegt hat. Wenn Sie sich Sorgen machen, dass Sie ihm vertrauen, können Sie jederzeit in den Benutzer schauen, um zu sehen, was er in der Vergangenheit mit Arch getan hat.

Fügen Sie Ihrem Schlüsselbund einen PGP-Schlüssel hinzu

So fügen Sie den Fingerabdruck Ihrem Schlüsselbund hinzu:

$ gpg --recv-keys <FINGERPRINT>

Sie können jetzt ausführen YOUR BUILDERund es wird dem Fingerabdruck vertrauen.

AUR-Entwicklungspakete

AUR - Pakete mit Namen mit der Endung -git, -svn, -bzroder -hgsind Entwicklungsversionen, die sich stromaufwärts des neuesten Versionskontrollsystem verwenden wollen, verpflichten statt Upstream neueste Version ist. Zum Beispiel a-gitDas Paket verwendet das neueste Commit von upstream im Hauptzweig (oder dem entsprechenden Zweig). Dies ist ideal, um Upstream-Fehlerkorrekturen und neue Funktionen auszuführen, die noch nicht veröffentlicht wurden, und wenn Sie mit Upstream an einem Fehler arbeiten, den Sie melden, einschließlich if Sie müssen überprüfen, ob es sich um einen Fehler handelt, der durch ein Commit behoben wurde, das noch nicht in einer Version enthalten ist. Diese Pakete sollten als potenziell instabil angesehen werden. Leider gibt es manchmal keine Alternative, da einige Upstream-Betreuer Releases nie mit Tags versehen oder zwischen den Tagging-Releases übermäßig lange warten und erwarten, dass jeder sein letztes Commit verwendet. Abhängig vom Paket sind Sie möglicherweise die erste Person, die versucht, dieses Commit auszuführen. Abhängig von den Upstream-Entwicklern wird das neueste Commit möglicherweise nicht einmal kompiliert.

Es ist wichtig, einen häufigen Fehler zu verstehen. Kennzeichnen Sie ein AUR-Entwicklungspaket nicht als veraltet, nur weil es eine alte Versionsnummer enthält! Entwicklungspaketdateien PKGBUILDenthalten eine zusätzliche Funktion pkgver(), mit der ein aktualisierter PKGVERQuellcode des Upstreams automatisch analysiert wird . Ein gängiges Format für ein -gitPaket ist <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Ein Paket kann in der AUR als aufgeführt sein 5.0.0.r102.8d7b42ac21-1, da es darin enthalten ist PKGBUILD. Wenn Sie jedoch ein Paket erstellen, YOUR BUILDERwird es automatisch aktualisiert PKGVER, um den neu heruntergeladenen Quellcode wiederzugeben. In der Tat, wenn viele neue Versionen veröffentlicht wurden, sich aber im Erstellungsprozess nichts geändert hat, könnte eine solche PKGBUILDAuflistung einer alten Version dazu führen, dass etwas viel Neueres erstellt wird, wie z9.1.2.r53.2c9a41b723-1. Bei diesen Paketen handelt es sich bei der auf der Website aufgeführten Version lediglich um die neueste Version zu dem Zeitpunkt, als der AUR-Betreuer die zuletzt aktualisieren musste PKGBUILD.

AUR-Betreuer sollten das NICHT nur aktualisieren PKGVER, um neue Versionen wiederzugeben. Sie sollen dies nur tun, wenn neuere Upstream-Commits tatsächlich etwas anderes erfordern, um sich PKGBUILDzu ändern.

Kennzeichnen Sie ein AUR-Entwicklungspaket nur dann als veraltet, wenn Sie wissen, dass tatsächlich etwas nicht stimmt. Das heißt, Sie haben tatsächlich versucht, es zu verwenden, und es schlägt fehl, ein ordnungsgemäß formatiertes neues zu kompilieren oder zu analysieren PKGVER. Manchmal passieren Dinge, die den AUR-Betreuer dazu zwingen, die zu aktualisieren PKGBUILD, z. B. Änderungen der Upstream-Abhängigkeiten, Änderungen der configureOptionen, neue GCC-Versionen, die Fehler im Quellcode auffangen, die frühere nicht hatten, Änderungen der Upstream-Repository-Speicherorte oder Upstream-Entwickler, die ihre typische Version ändern ist innerhalb des Quellcodes diePKGVERAnalysefunktion. Verstehen Sie, dass selbst wenn das Kompilieren fehlschlägt oder funktioniert, dies entweder bedeuten kann, dass der AUR-Betreuer Änderungen an seinem Erstellungsprozess vornehmen muss, oder dass es sich um ein vorgelagertes Problem mit seinem Quellcode handeln kann, für das der AUR-Betreuer keine Verantwortung trägt.

Veraltete Pakete

Lesen Sie unbedingt den Abschnitt "AUR-Entwicklungspakete" oben, bevor Sie ein Paket als veraltet melden!

Wenn Upstream eine neuere Version für ein nicht entwicklungsbezogenes Paket als in veröffentlicht hat PKGBUILD, können Sie auf " Paket als veraltet kennzeichnen" klicken und eine Nachricht an den Betreuer eingeben. Verwenden Sie https://packages.archlinux.org für offizielle Repository-Pakete und https://aur.archlinux.org für AUR-Pakete. Eine hilfreiche Nachricht wäre die neue Versionsnummer und möglicherweise ein Link zur Release-Ankündigung oder zum Quellcode. Die Kennzeichnungsfunktion sendet Ihre Nachricht automatisch per E-Mail an den Betreuer.

Wenn bei einem AUR-Paket nach 2 Wochen keine Antwort erfolgt ist, können Sie auf "Anfrage senden" mit dem Typ "Orphan" klicken, wenn Sie einen vertrauenswürdigen Benutzer bitten möchten, den aktuellen Betreuer zu entfernen, und das Paket verwaist machen, wenn Der Betreuer antwortet nicht auf die verwaiste Anfrage. Im Allgemeinen reichen Personen nur dann verwaiste Anfragen ein, wenn sie in der Lage und bereit sind, das Paket zu übernehmen, und vorzugsweise nur, wenn sie bereits über einen funktionierenden Strom verfügen PKGBUILD.

In der Zwischenzeit können Sie ein veraltetes Paket häufig selbst aktualisieren. Oft müssen Sie a nur ändern, PKGBUILDindem Sie die PKGVERauf die neue Versionsnummer aktualisieren, und die Integritätssummen werden aktualisiert. Im updpkgsumsPaket pacman-contribist ein Programm vorhanden , das die Summen automatisch berechnet und im PKGBUILDfür Sie aktualisiert . Es lohnt sich, die Versionshinweise von upstream zu lesen, um festzustellen, ob sich während des Installationsprozesses der neuen Version etwas ändern muss. Manchmal erfordern vorgelagerte Änderungen weitere Änderungen oder Überholungen PKGBUILD/ETC. Oft ist das sourceArray darin eingebettet PKGVER, so dass oft nicht einmal eine Aktualisierung erforderlich ist.