Bygga paket på Arch Linux (inklusive AUR)

På Arch Linux är de officiella förråden: kärna, extra och community. Dessa paket är redan kompilerade och de installeras via pacman. För det mesta kan allmänna användare ignorera att dessa 3 officiella förråd är separata. Core innehåller de mest kritiska paketen, såsom kärnan, startprocessen, nätverk, pakethantering, openssh och så vidare. Den har också strängare krav på mer grundliga tester innan nya versioner släpps. Extra innehåller andra populära paket som inte är lika kritiska, som en X-server, fönsterhanterare eller webbläsare. Community innehåller mindre populära paket. Endast betrodda användare (cirka 60 aktiva användare som röstades fram av andra betrodda användare) har tillgång att göra ändringar i de officiella arkiven.

Under 2019 finns det cirka 11 000 paket i de officiella förråden, på https://www.archlinux.org/packages . Men det finns många andra program tillgängliga på Linux. Så, AUR (Arch Linux User Repository) existerar så att alla Arch-användare kan lägga till ett nytt program och bli dess underhållare, eller anta ett "föräldralöst" paket utan en nuvarande underhållare. Det finns cirka 55 000 paket i AUR, på https://aur.archlinux.org/ .

Det finns 3 kritiska skillnader med AUR:

1. Återigen, dessa paket kan produceras av alla användare, även en helt ny.
2. AUR:n innehåller bara ett PKGBUILD, ett skalskript för att automatiskt göra paketet, inte kompilerade binärer. (Ibland innehåller den också små textkorrigeringar, eller installera/uppgradera/avinstallera skalskript). Detta har gjort ett fantastiskt jobb genom att tillåta alla användare att bidra, samtidigt som risken för att någon ska kunna distribuera skadlig kod minskat. Arch-gemenskapen är fortfarande till stor hjälp när det gäller problem med AUR-paket, men det noteras att användningen av dem sker på egen risk. Eftersom allt det ger är en PKGBUILD, är det i slutändan ditt ansvar att granska en PKGBUILDdu ska använda. (Visst, många användare gör inte detta och litar bara på att andra håller koll.)
3. Eftersom pacmandet inte interagerar direkt med AUR, är det ditt ansvar att uppdatera AUR-paket. När du regelbundet uppgraderar hela ditt system genom pacmankommer det inte automatiskt att ladda ner uppdateringar till AUR- PKGBUILDfiler, kompilera dem och installera dem åt dig.

Även om den här artikeln fokuserar på att bygga paket från AUR, kan samma tekniker användas för att själv bygga paket från de officiella arkiven.

PKGBUILD

Jämfört med en .specfil som många andra distributioner använder, PKGBUILDär a ett kort och enkelt skalskript. Även om vissa paket är mer komplexa kan de helt enkelt likna följande:

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
}

Detta dokument hänvisar till:

• PKGNAME: Namnet på ett paket
• PKGVER: Versionen av ett paket (matchar nästan alltid uppströms versionsnummer)
• PKGREL: Arch-"versionen" av PKGBUILDför en specifik PKGVER(normalt 1, men ökas om ändringar behöver göras i en PKGBUILDmellan uppströmsreleaser)
• ARCH: Arkitekturerna som paketet kan byggas på (något äldre, eftersom Arch Linux officiella förråd endast stöder "x86_64" (64-bitars processorer), men AUR-paket kan fortfarande stödja "i686" (32-bitars processorer) eller "alla" att beteckna arkitektur är irrelevant)
• PKGBUILD/ETC: Alla filer som faktiskt finns i AUR-förvaret; de PKGBUILD, och andra små text patchar eller installera / uppgradering / avinstallera skalskript. Inkluderar inte uppströmsfiler i sourcearrayen.

Även om AUR har visat sig vara extremt pålitlig, är det en bra idé att titta på en för PKGBUILD/ETCatt se till att den får källan från en plats du är villig att lita på; (till exempel en officiell uppströmsplats, som kan vara från github - men inte bara någon slumpmässig persons github-förråd som inte är relaterad till uppströmspaketet); och att den PKGBUILD/ETCinte innehåller någon misstänkt kod.

Erhållande PKGBUILD/ETC

Från AUR

Om de officiella förråden inte innehåller ett paket som du vill installera, sök efter det på https://aur.archlinux.org/ . Förhoppningsvis kommer du att upptäcka att det du letar efter finns, är uppdaterat och underhållet.

Det bästa sättet att få PKGBUILD/ETCfrån AUR är att klona den via git.

Installera git, om det inte redan är:

# pacman -S git

Använd "Git Clone URL" som visas på AUR-webbplatsen för det paketet:

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

Gå in i katalogen och titta på dess innehåll. (Allt listat här, förutom . .. .gitär PKGBUILD/ETC):

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

Om du undersöker PKGBUILDkommer du förhoppningsvis se att den använder den officiella uppströms källkoden och utför typiska steg för att bygga ett paket, så det verkar trovärdigt. Den .SRCINFOinnehåller bara informationen som visas på webbplatsen om paketet, så det är inte oroande. Om det finns några andra filer här, tillhandahålls de inte (direkt) av upstream, så filerna och hur de används i den PKGBUILDbör undersökas för att säkerställa att de inte innehåller något misstänkt.

Från officiella arkiv

Även om det krävs mycket mindre ofta, kan du bygga ett paket redan i de officiella förråden, för att inkludera en ny patch, bygga en nyare version, etc.

Skaffa PKGBUILD/ETCfrån kärnan och extra förråd:

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

Från gemenskapsarkivet:

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

Uppgraderar PKGBUILD/ETC

Om en uppgradering PKGBUILD/ETCsläpps kan du komma tillbaka till den här katalogen som skapats med git clone, och uppdatera dem:

$ git pull

Kompilera sedan om och uppgradera paketet med den metod du väljer nedan.

Sammanställning

Det finns många sätt att kompilera paket. I slutändan använder allt makepkg. Det finns två officiellt stödda sätt:

• För att använda direkt makepkg, se https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• För att indirekt använda makepkgi en rengöring chroot, se https://www.vultr.com/docs/using-devtools-on-arch-linux .

Det finns många AUR-hjälpprogram, (som makepkgomslaget), som inte officiellt stöds av Arch, som aurutils, yay, och den nyligen avvecklade aurmanoch yaourt. Även om du använder något av dessa andra hjälpprogram, rekommenderas det starkt att du bekantar dig med de officiellt stödda sätten att bli mer effektiv när något går fel.

Resten av det här dokumentet kommer YOUR BUILDERatt betyda vilken metod du än väljer.

Lokalt förråd

Du kan ställa in ett lokalt arkiv för att vara en central plats för alla paket du bygger.

Placera det lokala förvaret var du vill:

# mkdir /archLocalRepo

Kör YOUR BUILDERutan några automatiska installationsalternativ och kopiera paketet till ditt lokala arkiv.

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

Lägg till det nya paketet till förvarsindex:

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

Så här tar du bort ett paket från förvarets index och själva paketfilen:

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

Om du behöver ersätta en befintlig paketfil måste du separat ta bort den som ersätts och sedan lägga till den nya. Du kan inte bara kopiera den nya filen över den gamla.

Konfigurera för pacmanatt använda ditt lokala arkiv genom att redigera /etc/pacman.confoch lägg till följande i slutet:

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

Du måste ha pacmanuppdaterat sina kunskaper om arkiv, (inklusive din lokala), databaser; för att se paket som du har lagt till:

# pacman -Sy

Du kan sedan installera paketet, inte annorlunda än om det fanns i ett officiellt arkiv:

# pacman -S <PKGNAME>

Observera att om paketet bara är ett beroende av ett annat paket som du ska installera behöver du inte installera det direkt. När du installerar detta andra paket, pacmankommer automatiskt att hitta och installera beroendepaketen i ditt lokala arkiv.

Kompilera snabbare

Som standard, YOUR BUILDERkompilerar med en enda tråd. På multi-CPU-system kan du tillåta användning av flera trådar där det är möjligt. Byggsystemet kommer att kompilera delar av källkoden parallellt när det kan. Ibland kräver delar av koden att andra delar som den interagerar med redan är kompilerade, så du kommer inte alltid att se så många trådar som används som tillåts. Redigera /etc/makepkg.conf.

För att tillåta användning av så många trådar som du har virtuella kärnor, lägg till följande:

MAKEFLAGS="-j$(nproc)"

Obs: Detta kommer att köra kommandot nprocvarje gång, så det kommer alltid att använda det aktuella antalet kärnor, om du uppgraderar din Vultr-server

Lägg till ett specifikt antal för att tillåta användning av flera virtuella kärnor, men inte alla, till exempel för att minska påverkan på systemets övergripande prestanda. Till exempel, om du har 24 kärnor kan du tillåta att 21 används:

MAKEFLAGS="-j21"

Om du anger fler trådar än antalet virtuella kärnor du har minskar prestandan.

Det är ganska sällsynt, men vissa pakets byggsystem har problem med parallell kompilering, från att inte korrekt definiera beroenden mellan delar av koden. Vanligtvis kommer dessa pakets PKGBUILDfiler att hantera detta åt dig genom att anropa make -j1, vilket åsidosätter standardinställningen du anger. Om det behöver detta och det saknas, rapportera det till Arch-paketets underhållare.

PGP-signaturfel

En PKGBUILDkällmatris kan innehålla .asceller .sigfiler. De ingår ofta med bash brace expansion, så det kan vara lätt att missa:

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

Om något av dessa format av signaturfiler ingår i källarrayen, YOUR BUILDERförsöker automatiskt verifiera uppströms källarkivets signatur. Signaturens PGP-nyckel måste finnas i användarens nyckelring; annars avbryts det med felet:

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

Det är viktigt att förstå att en GPG-nyckel kan visas på flera sätt. Dess fingeravtryck är 40 hexadecimala tecken, och är vad du alltid bör använda. Ett långt nyckel-ID är de sista 16 siffrorna och ett kort nyckel-ID är de sista 8 siffrorna. Även om kortare är bekvämt tillåter det dubbletter som ogiltigförklarar hela resonemanget bakom verifiering av signaturer. Ännu värre, angripare har varit kända för att generera falska nycklar som matchar kortare nycklar för högprofilerade utvecklare.

Skaffa och verifiera PGP-nyckelns fingeravtryck

Om du inte redan har testat att bygga paketet, ladda ner källorna som kommer att innehålla signaturfilen: (Om du försökte bygga, kommer den redan att finnas där)

$ makepkg --nobuild --noextract

För att få hela fingeravtrycket:

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

Helst bör du verifiera detta fingeravtryck från uppströms. För att vara säker bör upstream ge sina underhållares nycklar någonstans på sin webbplats eller i källan. Att bara söka efter nyckeln på en nyckelserver gör egentligen ingenting. En angripare kan enkelt skicka in en falsk nyckel, eftersom nyckelservrar inte verifierar äktheten. Nycklar kan signeras av andra nycklar, så om du redan har en nyckel som du litar på bör du vara ganska säker på att lita på alla nycklar som de har signerat.

Det kan vara en hel del jobb, speciellt när upstream inte publicerar sitt fingeravtryck eller placerar det någonstans som är lätt att hitta. Den PKGBUILDkommer att innehålla en validpgpkeysmatris, som tillsattes av Arch ansvariga. Om paketet är ett officiellt arkiv betyder det att en betrodd användare har placerat det där, och du bör vara ganska säker på att bara lita på allt som listas i arrayen. Om paketet finns i AUR, kom ihåg att det bara betyder att en annan Arch-användare placerade det där. Om du är orolig för att lita på det kan du alltid titta på användaren för att se vad de har gjort tidigare med Arch.

Lägg till PGP-nyckel till din nyckelring

Så här lägger du till fingeravtrycket till din nyckelring:

$ gpg --recv-keys <FINGERPRINT>

Du kan nu köra YOUR BUILDERoch det kommer att lita på fingeravtrycket.

AUR utvecklingspaket

AUR paket med namn som slutar -git, -svn, -bzreller -hgär utvecklingsversioner, som använder uppströms senaste versionshanteringssystem begår istället för uppströms är senaste versionen. Till exempel, en-gitpaketet skulle använda uppströms senaste commit i mastergrenen (eller motsvarande gren.) Detta är utmärkt för att köra uppströms buggfixar och nya funktioner som inte har släppts ännu, och när du arbetar med uppströms på en bugg som du rapporterar inklusive om du måste verifiera för dem att det inte är en bugg som har åtgärdats av en commit som ännu inte finns i en release. Dessa paket bör anses vara potentiellt instabila. Som sagt, tyvärr, ibland finns det inget alternativ eftersom vissa uppströmsunderhållare aldrig taggar releaser eller går överdrivet långt mellan taggning av releaser och förväntar sig att alla använder sin senaste commit. Beroende på paketet kan du vara den första personen som försöker köra den commit. Beroende på uppströmsutvecklarna kanske deras senaste commit inte ens kompileras,

Det är viktigt att förstå ett vanligt misstag. Flagga inte ett AUR-utvecklingspaket som inaktuellt bara för att det visar ett gammalt versionsnummer! Utvecklingspaketfiler PKGBUILDinnehåller en extra funktion pkgver()som används för att automatiskt analysera en uppdaterad PKGVERfrån upstreams källkod. Ett vanligt format för ett -gitpaket är <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Ett paket kan vara listat i AUR som 5.0.0.r102.8d7b42ac21-1, eftersom det är vad det PKGBUILDinnehåller. Men när du skapar ett paket YOUR BUILDERuppdateras det automatiskt för PKGVERatt återspegla den nyligen nedladdade källkoden. Faktum är att om många nya versioner har släppts, men ingenting har förändrats i byggprocessen, kan en sådan PKGBUILDlistning av en gammal version sluta bygga något mycket nyare, som t.ex.9.1.2.r53.2c9a41b723-1. För dessa paket är versionen som listas på webbplatsen helt enkelt den senaste versionen vid den tidpunkt då AUR-underhållaren senast var tvungen att uppdatera PKGBUILD.

AUR-underhållare ska INTE bara uppdatera för PKGVERatt återspegla nya versioner. De är bara tänkta att göra det när nyare uppströms commits faktiskt kräver något annat i PKGBUILDatt ändra.

Flagga bara ett utvecklings-AUR-paket inaktuellt om du vet att något faktiskt är fel. Det betyder att du faktiskt har försökt använda den och den misslyckas med att kompilera eller analysera en korrekt formaterad ny PKGVER. Ibland händer saker som tvingar AUR-underhållaren att uppdatera PKGBUILD, som att uppströmsberoenden ändras, configurealternativ ändras, nya GCC-versioner tar upp fel i källkoden som tidigare inte gjorde, uppströmsförvarsplatser ändras eller uppströmsutvecklare kommer att ändra var deras typiska version är inom källkoden bryter motPKGVERanalysfunktion. Förstå att även om det misslyckas med att kompilera eller fungera, kan detta antingen innebära att AUR-underhållaren behöver göra ändringar i sin byggprocess, eller så kan det vara ett uppströmsproblem med deras källkod som AUR-underhållaren inte har något ansvar för.

Föråldrade paket

Se till att läsa avsnittet "AUR Developmental Packages" ovan innan du rapporterar ett paket som inaktuellt!

Om upstream har släppt en nyare version för ett icke-utvecklingspaket än i PKGBUILD, kan du klicka på "Flagga paket inaktuellt" och skriva ett meddelande till underhållaren. Använd https://packages.archlinux.org för officiella repository-paket och https://aur.archlinux.org för AUR-paket. Ett användbart meddelande skulle vara det nya versionsnumret och kanske en länk till releasemeddelandet eller källkoden. Flaggningsfunktionen skickar automatiskt ditt meddelande via e-post till underhållaren.

På ett AUR-paket, om det inte har kommit något svar efter 2 veckor, kan du klicka på "Skicka begäran" med typen "Orphan", om du vill be en betrodd användare att ta bort den nuvarande underhållaren och göra paketet föräldralöst, om underhållaren svarar inte på den föräldralösa begäran. I allmänhet skickar folk bara in föräldralösa förfrågningar om de kan och vill ta över paketet, och helst bara om de redan har en fungerande ström PKGBUILD.

Under tiden kan du ofta själv uppdatera ett föråldrat paket. Ofta behöver du bara ändra a PKGBUILDgenom att uppdatera PKGVERtill det nya versionsnumret, och integritetssummor uppdateras. Ett program updpkgsumsfinns i paketet pacman-contrib, som automatiskt beräknar summorna och uppdaterar dem PKGBUILDför dig. Det är värt att kolla uppströms release notes, för att se om de nämner att något behöver ändras under installationsprocessen av den nya versionen. Ibland kräver uppströmsförändringar fler förändringar eller översyner för att PKGBUILD/ETC. Ofta sourcebäddas arrayen in PKGVERi den, så ofta behöver den inte ens uppdateras.