Pakketten bouwen op Arch Linux (inclusief de AUR)

• PKGBUILD
• PKGBUILD / ETC verkrijgen
• PKGBUILD / ETC upgraden
• Compileren
• Lokale opslagplaats
• Compileer sneller
• PGP-handtekeningfout
• AUR ontwikkelingspakketten
• Verouderde pakketten

Op Arch Linux zijn de officiële repositories: core, extra en community. Deze pakketten zijn al gecompileerd en worden geïnstalleerd via pacman. Voor het grootste deel kunnen algemene gebruikers negeren dat deze 3 officiële repositories gescheiden zijn. Core bevat de meest kritieke pakketten, zoals de kernel, het opstartproces, netwerken, pakketbeheer, openssh enzovoort. Het heeft ook strengere eisen voor grondiger testen voordat er nieuwe versies worden uitgebracht. Extra bevat andere populaire pakketten die niet zo kritisch zijn, zoals een X-server, windowmanagers of webbrowsers. Community bevat minder populaire pakketten. Alleen vertrouwde gebruikers (ongeveer 60 actieve gebruikers waarop door andere vertrouwde gebruikers is gestemd) hebben toegang om wijzigingen aan te brengen in de officiële opslagplaatsen.

In 2019 zijn er ongeveer 11.000 pakketten in de officiële repositories, op https://www.archlinux.org/packages . Maar er zijn veel andere programma's beschikbaar op Linux. De AUR (Arch Linux User Repository) bestaat dus, zodat elke Arch-gebruiker een nieuw programma kan toevoegen en de beheerder ervan kan worden, of een "wees" pakket kan aannemen zonder een huidige beheerder. Er zijn ongeveer 55.000 pakketten in de AUR, op https://aur.archlinux.org/ .

Er zijn 3 kritische verschillen met de AUR:

1. Nogmaals, deze pakketten kunnen door elke gebruiker worden geproduceerd, zelfs een geheel nieuwe.
2. De AUR bevat alleen een PKGBUILD, een shell-script om het pakket automatisch te maken, geen gecompileerde binaire bestanden. (Soms bevat het ook kleine tekstpatches of shell-scripts installeren / upgraden / verwijderen). Dit heeft geweldig werk geleverd, zodat elke gebruiker een bijdrage kan leveren, terwijl de kans wordt verkleind dat iemand kwaadaardige code kan verspreiden. De Arch-gemeenschap is nog steeds erg behulpzaam met betrekking tot problemen met AUR-pakketten, maar er wordt opgemerkt dat het gebruik ervan op eigen risico is. Omdat alles wat het biedt een is PKGBUILD, is het uiteindelijk uw verantwoordelijkheid om een ​​te beoordelen die PKGBUILDu gaat gebruiken. (Toegegeven, veel gebruikers doen dit niet en vertrouwen gewoon op anderen om de wacht te houden.)
3. Omdat pacmaner geen directe interactie is met de AUR, is het uw verantwoordelijkheid om AUR-pakketten bij te werken. Wanneer u uw volledige systeem periodiek pacmanupgradet PKGBUILD, worden updates voor AUR- bestanden niet automatisch gedownload, gecompileerd en voor u geïnstalleerd.

Hoewel dit artikel zich richt op het bouwen van pakketten vanuit de AUR, kunnen dezelfde technieken worden gebruikt om zelf pakketten te bouwen vanuit de officiële repositories.

PKGBUILD

Vergeleken met een .specbestand dat veel andere distributies gebruiken, PKGBUILDis a een kort en eenvoudig shell-script. Hoewel sommige pakketten complexer zijn, kunnen ze er simpelweg als volgt uitzien:

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
}

Dit document verwijst naar:

• PKGNAME: De naam van een pakket
• PKGVER: De versie van een pakket (bijna altijd overeenkomend met het upstream-versienummer)
• PKGREL: De Arch "versie" van de PKGBUILDvoor een specifieke PKGVER(normaal 1, maar opgehoogd als er wijzigingen moeten worden aangebracht in een PKGBUILDtussen upstream releases)
• ARCH: De architecturen waarop het pakket kan worden gebouwd (enigszins verouderd, aangezien de officiële archieven van Arch Linux alleen "x86_64" (64-bits CPU's) ondersteunen, maar AUR-pakketten kunnen nog steeds "i686" (32-bits CPU's) of "elke" ondersteunen architectuur aanwijzen is niet relevant)
• PKGBUILD/ETC: Alle bestanden die daadwerkelijk in de AUR-repository staan; de PKGBUILD, en andere kleine tekstpatches, of shell-scripts installeren / upgraden / verwijderen. Bevat geen upstream-bestanden in de sourcearray.

Hoewel de AUR uiterst betrouwbaar is gebleken, is het een goed idee om naar A te kijken PKGBUILD/ETCom er zeker van te zijn dat het de bron haalt van een plek die u bereid bent te vertrouwen; (bijvoorbeeld een officiële upstream-locatie, die afkomstig kan zijn van github - maar niet alleen de github-repository van een willekeurige persoon die geen verband houdt met het upstream-pakket); en dat het PKGBUILD/ETCgeen verdachte code bevat.

Het verkrijgen van PKGBUILD/ETC

Van de AUR

Als de officiële repositories geen pakket bevatten dat u wilt installeren, zoekt u ernaar op https://aur.archlinux.org/ . Hopelijk zul je merken dat wat je zoekt bestaat, up-to-date en onderhouden is.

De beste manier om het PKGBUILD/ETCvan de AUR te verkrijgen, is door het via te klonen git.

Installeer git, als dit nog niet het geval is:

# pacman -S git

Gebruik de "Git Clone URL" op de AUR-website voor dat pakket:

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

Voer de directory in en bekijk de inhoud. (Alles hier vermeld, behalve de . .. .gitis PKGBUILD/ETC):

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

Als je het onderzoekt PKGBUILD, zul je hopelijk zien dat het de officiële upstream-broncode gebruikt en typische stappen uitvoert om een ​​pakket te bouwen, dus het lijkt betrouwbaar. Het .SRCINFObevat alleen de informatie die op de website over het pakket wordt weergegeven, dus is niet zorgwekkend. Als er hier andere bestanden zijn, worden deze niet (rechtstreeks) door upstream geleverd, dus de bestanden en hoe ze in de bestanden worden gebruikt, PKGBUILDmoeten worden onderzocht om er zeker van te zijn dat ze niets verdachts bevatten.

Van officiële opslagplaatsen

Hoewel het veel minder vaak nodig is, kunt u al een pakket in de officiële repositories bouwen, een nieuwe patch toevoegen, een nieuwere versie bouwen, enz.

Verkrijg PKGBUILD/ETCuit de kern en extra opslagplaatsen:

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

Van de community-repository:

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

Upgraden PKGBUILD/ETC

Als er een upgrade PKGBUILD/ETCis uitgebracht, kunt u teruggaan naar deze map die is gemaakt met git cloneen deze bijwerken:

$ git pull

Hercompileer en upgrade vervolgens het pakket met de methode van uw keuze hieronder.

Compileren

Er zijn veel manieren om pakketten samen te stellen. Uiteindelijk gebruikt alles makepkg. Er zijn 2 officieel ondersteunde manieren:

• makepkgZie https://www.vultr.com/docs/using-makepkg-on-arch-linux om direct te gebruiken .
• Voor indirect gebruik makepkgin een clean chroot, zie https://www.vultr.com/docs/using-devtools-on-arch-linux .

Er zijn veel AUR helper programma's (zoals de makepkgwrapper), die niet officieel worden ondersteund door Arch, zoals aurutils, yayen de recent gestaakt aurmanen yaourt. Zelfs als u een van deze andere helperprogramma's gebruikt, wordt het ten zeerste aanbevolen vertrouwd te raken met de officieel ondersteunde manieren om effectiever te zijn als er iets misgaat.

De rest van dit document geeft YOUR BUILDERaan welke methode u ook kiest.

Lokale opslagplaats

U kunt een lokale repository instellen als centrale locatie voor alle pakketten die u maakt.

Plaats de lokale repository waar je maar wilt:

# mkdir /archLocalRepo

Voer uit YOUR BUILDERzonder automatische installatieopties en kopieer het pakket naar uw lokale repository.

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

Voeg het nieuwe pakket toe aan de repository-index:

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

Een pakket verwijderen uit de index van de repository en het pakketbestand zelf:

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

Als u een bestaand pakketbestand moet vervangen, moet u het te vervangen bestand afzonderlijk verwijderen en vervolgens het nieuwe toevoegen. U kunt het nieuwe bestand niet zomaar over het oude heen kopiëren.

Configureer pacmanom uw lokale repository te gebruiken door te bewerken /etc/pacman.confen voeg aan het einde het volgende toe:

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

U moet pacmande kennis van de repository (inclusief uw lokale), databases, vernieuwen; om pakketten te zien die je eraan hebt toegevoegd:

# pacman -Sy

Vervolgens kunt u het pakket installeren, niet anders dan wanneer het zich in een officiële repository bevond:

# pacman -S <PKGNAME>

Merk op dat als het pakket slechts een afhankelijkheid is van een ander pakket dat u gaat installeren, u het niet direct hoeft te installeren. Wanneer u dit andere pakket installeert, pacmanvindt en installeert het automatisch de afhankelijkheidspakketten in uw lokale repository.

Compileer sneller

Compileert standaard YOUR BUILDERmet één enkele thread. Op systemen met meerdere CPU's kunt u toestaan ​​waar mogelijk meerdere threads te gebruiken. Het build-systeem compileert indien mogelijk delen van de broncode parallel. Soms vereisen delen van code dat andere delen waarmee het samenwerkt, al zijn gecompileerd, dus u zult niet altijd zien hoeveel threads worden gebruikt dan toegestaan. Bewerken /etc/makepkg.conf.

Om het gebruik van zoveel threads toe te staan ​​als u virtuele cores heeft, voegt u het volgende toe:

MAKEFLAGS="-j$(nproc)"

Opmerking: dit zal de opdracht nprocelke keer uitvoeren, dus het zal altijd het huidige aantal cores gebruiken, voor het geval u uw Vultr-server upgradet

Voeg een specifiek nummer toe om het gebruik van meerdere virtuele kernen toe te staan, maar niet allemaal, zoals het verminderen van de impact op de algehele systeemprestaties. Als u bijvoorbeeld 24 kernen heeft, kunt u toestaan ​​dat er 21 worden gebruikt:

MAKEFLAGS="-j21"

Als u meer threads specificeert dan het aantal virtuele cores dat u heeft, nemen de prestaties af.

Het is vrij zeldzaam, maar sommige build-systemen van pakketten hebben problemen met parallelle compilatie, omdat ze de afhankelijkheden tussen delen van code niet goed definiëren. Meestal zullen de PKGBUILDbestanden van die pakketten dit voor u afhandelen door een beroep te doen op make -j1de standaard die u instelt. Als het dit nodig heeft en het ontbreekt, meld dit dan aan de Arch-pakketbeheerder.

PGP-handtekeningfout

Een PKGBUILDsource array kan .ascof .sigbestanden bevatten . Ze worden vaak meegeleverd met bash-brace-uitbreiding, dus het kan gemakkelijk zijn om te missen:

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

Als een van deze formaten van handtekeningbestanden is opgenomen in de bronarray, wordt YOUR BUILDERautomatisch geprobeerd de handtekening van het upstream-bronarchief te verifiëren. De PGP-sleutel van de handtekening moet in de sleutelring van de gebruiker zitten; anders wordt de fout afgebroken:

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

Het is belangrijk om te begrijpen dat een GPG-sleutel op verschillende manieren kan worden getoond. De vingerafdruk bestaat uit 40 hexadecimale tekens en is wat u altijd moet gebruiken. Een lange sleutel-ID is de laatste 16 cijfers en een korte sleutel-ID is de laatste 8 cijfers. Hoewel korter handig is, maakt het duplicaten mogelijk die de hele redenering achter het verifiëren van handtekeningen ongeldig maken. Erger nog, van aanvallers is bekend dat ze valse sleutels genereren die overeenkomen met sleutels van kleinere lengte voor vooraanstaande ontwikkelaars.

Verkrijg en verifieer de vingerafdruk van de PGP-sleutel

Als je nog niet hebt geprobeerd het pakket te bouwen, download dan de bronnen die het handtekeningbestand zullen bevatten: (Als je hebt geprobeerd te bouwen, zal het er al zijn)

$ makepkg --nobuild --noextract

Om de volledige vingerafdruk te verkrijgen:

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

Idealiter zou u deze vingerafdruk van stroomopwaarts moeten verifiëren. Om veilig te zijn, zou upstream de sleutels van de beheerders ergens op de website of in de bron moeten geven. Alleen zoeken naar de sleutel op een sleutelserver doet eigenlijk niets. Een aanvaller kan gemakkelijk een nep-sleutel indienen, omdat sleutelservers de authenticiteit niet verifiëren. Sleutels kunnen worden ondertekend door andere sleutels, dus als u al een sleutel heeft die u vertrouwt, moet u redelijk veilig zijn op alle sleutels die ze hebben ondertekend.

Dat kan nogal wat werk zijn, vooral als upstream hun vingerafdruk niet publiceert of ergens gemakkelijk vindbaar maakt. Het PKGBUILDzal een validpgpkeysarray bevatten die door de Arch-beheerder is toegevoegd. Als het pakket een officiële repository is, betekent dit dat een vertrouwde gebruiker het daar heeft geplaatst, en je zou redelijk veilig moeten zijn om alles wat in de array staat te vertrouwen. Als het pakket zich in de AUR bevindt, onthoud dan dat dit betekent dat een andere Arch-gebruiker het daar heeft geplaatst. Als je bang bent om het te vertrouwen, kun je altijd naar de gebruiker kijken om te zien wat ze in het verleden met Arch hebben gedaan.

Voeg PGP-sleutel toe aan uw sleutelhanger

Om de vingerafdruk aan je sleutelhanger toe te voegen:

$ gpg --recv-keys <FINGERPRINT>

Je kunt nu rennen YOUR BUILDERen het zal de vingerafdruk vertrouwen.

AUR ontwikkelingspakketten

AUR pakketten met namen die eindigen -git, -svn, -bzrof -hgzijn ontwikkelings versies, die stroomopwaarts van de laatste versie gebruiken besturingssysteem te plegen in plaats van stroomopwaarts is de nieuwste release. Bijvoorbeeld een-gitpakket zou de laatste commit van upstream in de master -branch gebruiken (of hun equivalente branch.) Dit is geweldig voor het uitvoeren van upstream-bugfixes en nieuwe functies die nog niet zijn vrijgegeven, en wanneer je met upstream aan een bug werkt, rapporteer je inclusief of je moet voor hen verifiëren dat het geen bug is die is opgelost door een commit die nog niet in een release zit. Deze pakketten moeten als mogelijk onstabiel worden beschouwd. Dat gezegd hebbende, helaas is er soms geen alternatief omdat sommige upstream-beheerders nooit releases taggen of buitensporig lang gaan tussen het taggen van releases en verwachten dat iedereen zijn meest recente commit gebruikt. Afhankelijk van het pakket, zou je de eerste persoon kunnen zijn die die commit probeert uit te voeren. Afhankelijk van de upstream ontwikkelaars, zal hun laatste commit misschien niet eens compileren,

Het is belangrijk om een ​​veelgemaakte fout te begrijpen. Markeer een AUR-ontwikkelingspakket niet als verouderd, simpelweg omdat het een oud versienummer toont! Ontwikkelingspakketbestanden PKGBUILDbevatten een extra functie pkgver(), die wordt gebruikt om automatisch een bijgewerkte versie PKGVERvan de broncode upstream te parseren . Een algemeen formaat voor een -gitpakket is <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Een pakket kan in de AUR worden vermeld als 5.0.0.r102.8d7b42ac21-1, omdat dat is wat het PKGBUILDbevat. Maar wanneer u een pakket maakt, YOUR BUILDERwordt het automatisch bijgewerkt PKGVERom de nieuw gedownloade broncode weer te geven. In feite, als er veel nieuwe versies zijn uitgebracht, maar er is niets veranderd in het bouwproces, zou zo'n PKGBUILDlijst met een oude versie ertoe kunnen leiden dat er iets veel nieuws wordt gebouwd, zoals9.1.2.r53.2c9a41b723-1. Voor deze pakketten is de op de website vermelde versie gewoon de nieuwste versie op het moment dat de AUR-beheerder de laatste moest bijwerken PKGBUILD.

AUR-beheerders mogen de update NIET alleen bijwerken PKGVERom nieuwe versies weer te geven. Ze mogen dit alleen doen als nieuwere upstream-commits eigenlijk iets anders nodig hebben PKGBUILDom te veranderen.

Markeer een ontwikkelings-AUR-pakket alleen verouderd als u weet dat er iets mis is. Dit betekent dat u het daadwerkelijk hebt geprobeerd te gebruiken en dat het mislukt bij het compileren of parsen van een goed opgemaakte nieuwe PKGVER. Soms gebeuren er dingen die de AUR-beheerder dwingen om de PKGBUILD, zoals wijziging van upstream-afhankelijkheden, wijziging van configureopties, nieuwe GCC-versies fouten in de broncode op te pikken die eerdere niet deden, upstream-opslagplaatslocaties veranderen of upstream-ontwikkelaars veranderen waar hun typische versie is binnen de broncode die dePKGVERparseerfunctie. Begrijp dat zelfs als het compileren of werken mislukt, dit kan betekenen dat de AUR-beheerder wijzigingen moet aanbrengen in zijn bouwproces, of dat het een upstream-probleem kan zijn met zijn broncode waarvoor de AUR-beheerder geen verantwoordelijkheid draagt.

Verouderde pakketten

Zorg ervoor dat u het gedeelte "AUR-ontwikkelingspakketten" hierboven leest voordat u een pakket als verouderd meldt!

Als upstream een ​​nieuwere versie heeft uitgebracht voor een niet-ontwikkelingspakket dan in het PKGBUILD, kunt u op "Pakket verouderd markeren" klikken en een bericht naar de onderhouder typen. Gebruik https://packages.archlinux.org voor officiële repository-pakketten en https://aur.archlinux.org voor AUR-pakketten. Een nuttig bericht is het nieuwe versienummer en misschien een link naar de aankondiging van de release of de broncode. De markeringsfunctie e-mailt automatisch uw bericht naar de onderhouder.

Als er bij een AUR-pakket na 2 weken geen reactie is, kunt u op "Aanvraag indienen" met type "Orphan" klikken, als u een vertrouwde gebruiker wilt vragen om de huidige onderhouder te verwijderen en het pakket wees te maken, als de beheerder reageert niet op het weesverzoek. Over het algemeen dienen mensen alleen weesaanvragen in als ze het pakket kunnen en willen overnemen, en het liefst alleen als ze al een werkende stroom hebben PKGBUILD.

In de tussentijd kun je vaak zelf een verouderd pakket updaten. Vaak hoeft u alleen a te wijzigen PKGBUILDdoor het bij te werken PKGVERnaar het nieuwe versienummer en de integriteitssommen worden bijgewerkt. Er updpkgsumsbestaat een programma in pakket pacman-contrib, dat automatisch de sommen berekent en deze PKGBUILDvoor u bijwerkt . Het is de moeite waard om de release-opmerkingen van upstream te controleren om te zien of ze vermelden dat er iets moet veranderen tijdens het installatieproces van de nieuwe versie. Soms vereisen stroomopwaartse wijzigingen meer wijzigingen of revisies PKGBUILD/ETC. Vaak is de sourcearray PKGVERerin ingesloten , dus vaak hoeft deze niet eens te worden bijgewerkt.