Opbygning af pakker på Arch Linux (inklusive AUR)

På Arch Linux er de officielle depoter: kerne, ekstra og fællesskab. Disse pakker er allerede kompileret, og de er installeret gennem pacman. For det meste kan generelle brugere ignorere, at disse 3 officielle arkiver er adskilte. Core indeholder de mest kritiske pakker, såsom kernen, opstartsprocessen, netværk, pakkehåndtering, openssh og så videre. Det har også strengere krav om mere grundig test, før nye versioner udgives. Extra indeholder andre populære pakker, der ikke er så kritiske, såsom en X-server, vinduesadministratorer eller webbrowsere. Community indeholder mindre populære pakker. Kun betroede brugere (ca. 60 aktive brugere, der blev stemt på af andre betroede brugere) har adgang til at foretage ændringer i de officielle arkiver.

I 2019 er der omkring 11.000 pakker i de officielle arkiver på https://www.archlinux.org/packages . Men der er mange andre programmer tilgængelige på Linux. Så AUR (Arch Linux User Repository) eksisterer, så enhver Arch-bruger kan tilføje et nyt program og blive dets vedligeholder, eller adoptere en "forældreløs" pakke uden en aktuel vedligeholder. Der er omkring 55.000 pakker i AUR på https://aur.archlinux.org/ .

Der er 3 kritiske forskelle med AUR:

1. Igen kan disse pakker produceres af enhver bruger, selv en helt ny.
2. AUR'en indeholder kun et PKGBUILD, et shell-script til automatisk at lave pakken, ikke kompilerede binære filer. (Nogle gange indeholder den også små tekstrettelser eller installer/opgrader/afinstaller shell-scripts). Dette har gjort et enormt stykke arbejde ved at give enhver bruger mulighed for at bidrage, samtidig med at det mindsker chancen for, at nogen er i stand til at distribuere ondsindet kode. Arch-fællesskabet er stadig ret hjælpsomt med hensyn til problemer med AUR-pakker, men det bemærkes, at brugen af ​​dem er på eget ansvar. Fordi alt det giver er en PKGBUILD, er det i sidste ende dit ansvar at gennemgå en PKGBUILDdu skal bruge. (Ja, mange brugere gør ikke dette og stoler bare på, at andre holder øje.)
3. Fordi pacmandet ikke interagerer direkte med AUR, er det dit ansvar at opdatere AUR-pakker. Når du periodisk opgraderer hele dit system gennem pacman, vil det ikke automatisk downloade opdateringer til AUR- PKGBUILDfiler, kompilere dem og installere dem for dig.

Selvom denne artikel fokuserer på at bygge pakker fra AUR, kan de samme teknikker bruges til selv at bygge pakker fra de officielle repositories.

PKGBUILD

Sammenlignet med en .specfil, som mange andre distributioner bruger, PKGBUILDer a et kort og simpelt shell-script. Selvom nogle pakker er mere komplekse, kan de simpelthen ligne følgende:

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
}

Dette dokument refererer til:

• PKGNAME: Navnet på en pakke
• PKGVER: Versionen af ​​en pakke (matcher næsten altid upstreams versionsnummer)
• PKGREL: Arch "versionen" af PKGBUILDfor en specifik PKGVER(normalt 1, men øget, hvis der skal foretages ændringer i en PKGBUILDmellem opstrøms udgivelser)
• ARCH: Arkitekturerne pakken kan bygges på (noget ældre, da Arch Linux officielle repositories kun understøtter "x86_64" (64-bit CPU'er), men AUR-pakker kan stadig understøtte "i686" (32-bit CPU'er) eller "enhver" at udpege arkitektur er irrelevant)
• PKGBUILD/ETC: Alle filer, der faktisk findes i AUR-lageret; de PKGBUILDog alle andre små tekst patches, eller installere / opgradere / afinstallere skalskripter. Inkluderer ikke upstream-filer i sourcearrayet.

Selvom AUR har vist sig at være ekstremt troværdig, er det en god idé at se på en PKGBUILD/ETCfor at sikre, at den får kilden fra et sted, du er villig til at stole på; (for eksempel en officiel opstrømsplacering, som kan være fra github - men ikke bare en tilfældig persons github-lager, som ikke er relateret til opstrømspakken); og at den PKGBUILD/ETCikke indeholder nogen mistænkelig kode.

Indhentning PKGBUILD/ETC

Fra AUR

Hvis de officielle depoter ikke indeholder en pakke, du ønsker at installere, skal du søge efter den på https://aur.archlinux.org/ . Forhåbentlig vil du opdage, at det, du leder efter, findes, er opdateret og vedligeholdt.

Den bedste måde at få PKGBUILD/ETCfra AUR er at klone den via git.

Installer git, hvis det ikke allerede er:

# pacman -S git

Brug "Git Clone URL" vist på AUR-webstedet for den pakke:

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

Gå ind i mappen og se på dens indhold. (Alt anført her, undtagen . .. .giter PKGBUILD/ETC):

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

Hvis du undersøger PKGBUILD, vil du forhåbentlig se, at den bruger den officielle upstream-kildekode og udfører typiske trin for at bygge en pakke, så den virker troværdig. Den .SRCINFOindeholder blot de oplysninger, der vises på hjemmesiden om pakken, så det er ikke bekymrende. Hvis der er andre filer her, er de ikke (direkte) leveret af upstream, så filerne og hvordan de bruges i den PKGBUILDbør undersøges for at sikre, at de ikke indeholder noget mistænkeligt.

Fra officielle arkiver

Selvom det kræves meget sjældnere, kan du bygge en pakke allerede i de officielle arkiver for at inkludere en ny patch, bygge en nyere version osv.

Få PKGBUILD/ETCfra kerne- og ekstralagrene:

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

Fra community-depotet:

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

Opgradering PKGBUILD/ETC

Hvis en opgraderet PKGBUILD/ETCer frigivet, kan du vende tilbage til denne mappe lavet ved hjælp af git clone, og opdatere dem:

$ git pull

Genkompiler og opgrader derefter pakken ved at bruge den metode, du vælger, nedenfor.

Kompilere

Der er mange måder at kompilere pakker på. I sidste ende bruger alt makepkg. Der er 2 officielt understøttede måder:

• For direkte brug makepkg, se https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• For indirekte brug makepkgi en rengøring chroot, se https://www.vultr.com/docs/using-devtools-on-arch-linux .

Der er mange AUR-hjælpeprogrammer (såsom makepkgindpakningen), der ikke er officielt understøttet af Arch, såsom aurutils, yay, og den nyligt udgåede aurmanog yaourt. Selvom du bruger et af disse andre hjælpeprogrammer, anbefales det kraftigt at blive fortrolig med de officielt understøttede måder at være mere effektiv på, når noget går galt.

Resten af ​​dette dokument vil bruge YOUR BUILDERtil at betyde, hvilken metode du end vælger.

Lokalt depot

Du kan konfigurere et lokalt lager til at være et centralt sted for alle pakker, du bygger.

Placer det lokale lager, hvor du vil:

# mkdir /archLocalRepo

Kør YOUR BUILDERuden nogen automatiske installationsmuligheder, og kopier pakken til dit lokale lager.

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

Tilføj den nye pakke til lagerindekset:

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

Sådan fjerner du en pakke fra lagerets indeks og selve pakkefilen:

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

Hvis du skal erstatte en eksisterende pakkefil, skal du separat fjerne den, der erstattes, og derefter tilføje den nye. Du kan ikke bare kopiere den nye fil over den gamle.

Konfigurer pacmantil at bruge dit lokale lager ved at redigere /etc/pacman.conf, og tilføj følgende til sidst:

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

Du skal have pacmangenopfrisket dets viden om repository, (inklusive din lokale), databaser; for at se pakker, du har tilføjet til det:

# pacman -Sy

Du kan derefter installere pakken, ikke anderledes end hvis den var i et officielt lager:

# pacman -S <PKGNAME>

Bemærk, at hvis pakken kun er en afhængighed af en anden pakke, du skal installere, behøver du ikke installere den direkte. Når du installerer denne anden pakke, pacmanvil du automatisk finde og installere afhængighedspakkerne i dit lokale lager.

Kompiler hurtigere

Kompilerer som standard ved YOUR BUILDERhjælp af en enkelt tråd. På multi-CPU-systemer kan du tillade brug af flere tråde, hvor det er muligt. Byggesystemet vil kompilere dele af kildekoden parallelt, når det kan. Nogle gange kræver dele af koden, at andre dele, den interagerer med, allerede er kompileret, så du vil ikke altid se så mange tråde, der bruges, som tilladt. Rediger /etc/makepkg.conf.

For at tillade brug af så mange tråde, som du har virtuelle kerner, skal du tilføje følgende:

MAKEFLAGS="-j$(nproc)"

Bemærk: Dette vil køre kommandoen nprochver gang, så det vil altid bruge det aktuelle antal kerner, hvis du opgraderer din Vultr-server

Tilføj et specifikt tal for at tillade brug af flere virtuelle kerner, men ikke dem alle, f.eks. for at reducere indvirkningen på den samlede systemydelse. For eksempel, hvis du har 24 kerner, kan du tillade, at 21 bruges:

MAKEFLAGS="-j21"

Angivelse af flere tråde end antallet af virtuelle kerner, du har, vil reducere ydeevnen.

Det er ret sjældent, men nogle pakkers byggesystemer har problemer med parallel kompilering, fordi de ikke definerer afhængigheder mellem dele af koden korrekt. Typisk vil disse pakkers PKGBUILDfiler håndtere dette for dig ved at påkalde make -j1, som tilsidesætter den standard, du angiver. Hvis det har brug for dette, og det mangler, skal du rapportere det til Arch-pakkens vedligeholder.

PGP-signaturfejl

Et PKGBUILDkildearray kan indeholde .asceller .sigfiler. De er ofte inkluderet ved hjælp af bash brace-udvidelse, så de kan være nemme at gå glip af:

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

Hvis et af disse formater af signaturfiler er inkluderet i kildearrayet, YOUR BUILDERforsøger det automatisk at verificere upstream-kildearkivets signatur. Signaturens PGP-nøgle skal være i brugerens nøglering; ellers vil den afbryde med fejlen:

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

Det er vigtigt at forstå, at en GPG-nøgle kan vises på flere måder. Dens fingeraftryk er på 40 hexadecimale tegn, og det er det, du altid bør bruge. Et langt nøgle-id er de sidste 16 cifre, og et kort nøgle-id er de sidste 8 cifre. Selvom kortere er praktisk, tillader det dubletter, hvilket annullerer hele ræsonnementet bag verificering af signaturer. Værre er det, at angribere har været kendt for at generere falske nøgler, der matcher nøgler med mindre længde til højt profilerede udviklere.

Få og bekræft PGP-nøglefingeraftryk

Hvis du ikke allerede har prøvet at bygge pakken, skal du downloade kilderne, som inkluderer signaturfilen: (Hvis du prøvede at bygge, vil den allerede være der)

$ makepkg --nobuild --noextract

Sådan får du det fulde fingeraftryk:

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

Ideelt set bør du verificere dette fingeraftryk fra opstrøms. For at være sikker bør upstream give sine vedligeholderes nøgler et sted på sin hjemmeside eller i kilden. Blot at søge efter nøglen på en nøgleserver gør ikke rigtig noget. En angriber kan nemt indsende en falsk nøgle, fordi nøgleservere ikke bekræfter ægtheden. Nøgler kan signeres af andre nøgler, så hvis du allerede har en nøgle, du stoler på, bør du være ret sikker på at stole på alle nøgler, de har underskrevet.

Det kan være en del arbejde, især når upstream ikke offentliggør deres fingeraftryk eller placerer det et sted, der er let at finde. Den PKGBUILDvil indeholde et validpgpkeysarray, der blev tilføjet af Arch vedligeholder. Hvis pakken er et officielt lager, betyder det, at en betroet bruger har placeret den der, og du bør være ret sikker på at stole på alt, der er angivet i arrayet. Hvis pakken er i AUR'en, så husk, at det blot betyder, at en anden Arch-bruger har placeret den der. Hvis du er bekymret for at stole på det, kan du altid kigge på brugeren for at se, hvad de tidligere har gjort med Arch.

Tilføj PGP-nøgle til din nøglering

Sådan tilføjer du fingeraftrykket til din nøglering:

$ gpg --recv-keys <FINGERPRINT>

Du kan nu køre YOUR BUILDER, og den vil stole på fingeraftrykket.

AUR Udviklingspakker

AUR pakker med navne der ender -git, -svn, -bzreller -hger udviklingsmæssige versioner, der anvender opstrøms nyeste version control system begå stedet for opstrøms er seneste udgivelse. For eksempel, en-gitpakken vil bruge upstreams seneste commit i master-grenen (eller deres tilsvarende gren). Dette er fantastisk til at køre upstream-fejlrettelser og nye funktioner, der ikke er blevet frigivet endnu, og når du arbejder med upstream på en fejl, du rapporterer, herunder hvis du skal verificere for dem, at det ikke er en fejl, der er blevet rettet af en commit, der endnu ikke er i en udgivelse. Disse pakker bør betragtes som potentielt ustabile. Når det er sagt, er der desværre nogle gange ikke noget alternativ, fordi nogle upstream-vedligeholdere aldrig tagger udgivelser eller går alt for længe mellem tagging af udgivelser og forventer, at alle bruger deres seneste commit. Afhængigt af pakken kan du være den første person, der prøver at køre denne commit. Afhængigt af upstream-udviklerne kompilerer deres seneste commit muligvis ikke engang,

Det er vigtigt at forstå en almindelig fejl. Markér ikke en AUR-udviklingspakke som forældet, blot fordi den viser et gammelt versionsnummer! Udviklingspakkefiler PKGBUILDindeholder en ekstra funktion pkgver(), som bruges til automatisk at parse en opdateret PKGVERfra upstreams kildekode. Et almindeligt format for en -gitpakke er <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. En pakke kan være opført i AUR'en som 5.0.0.r102.8d7b42ac21-1, fordi det er, hvad den PKGBUILDindeholder. Men når du opretter en pakke, YOUR BUILDERopdateres den automatisk for PKGVERat afspejle den nyligt downloadede kildekode. Faktisk, hvis mange nye versioner er blevet frigivet, men intet har ændret sig i byggeprocessen, kan en sådan PKGBUILDliste over en gammel version ende med at bygge noget meget nyere, som f.eks.9.1.2.r53.2c9a41b723-1. For disse pakker er den version, der er angivet på webstedet, simpelthen den seneste version på det tidspunkt, hvor AUR-vedligeholderen sidst skulle opdatere PKGBUILD.

AUR-vedligeholdere skal IKKE bare opdatere for PKGVERat afspejle nye versioner. Det er kun meningen, at de skal gøre det, når nyere upstream-forpligtelser faktisk kræver noget andet i PKGBUILDat ændre.

Markér kun en udviklingsmæssig AUR-pakke forældet, hvis du ved, at noget rent faktisk er galt. Det betyder, at du faktisk har prøvet at bruge det, og det mislykkes med at kompilere eller parse en korrekt formateret ny PKGVER. Nogle gange sker der ting, der tvinger AUR-vedligeholderen til at opdatere PKGBUILD, som f.eks. ændringer i opstrømsafhængigheder, ændringer af configuremuligheder, nye GCC-versioner opfanger fejl i kildekoden, som tidligere ikke gjorde, opstrøms-lagerplaceringer ændrer sig, eller opstrømsudviklere vil ændre, hvor deres typiske version er inden for kildekoden, der bryderPKGVERparsing funktion. Forstå, at selvom det mislykkes med at kompilere eller fungere, kan dette enten betyde, at AUR-vedligeholderen skal foretage ændringer i deres byggeproces, eller det kan være et opstrømsproblem med deres kildekode, som AUR-vedligeholderen ikke har noget ansvar for.

Forældede pakker

Sørg for at læse afsnittet "AUR-udviklingspakker" ovenfor, før du rapporterer en pakke som værende forældet!

Hvis upstream har udgivet en nyere version for en ikke-udviklingspakke end i PKGBUILD, kan du klikke på "Flag pakke forældet" og skrive en besked til vedligeholderen. Brug https://packages.archlinux.org til officielle repository-pakker og https://aur.archlinux.org til AUR-pakker. En nyttig besked ville være det nye versionsnummer og måske et link til udgivelsesmeddelelsen eller kildekoden. Markeringsfunktionen sender automatisk din besked til vedligeholderen.

På en AUR-pakke, hvis der ikke har været noget svar efter 2 uger, kan du klikke på "Send anmodning" med typen "Forældreløs", hvis du vil bede en betroet bruger om at fjerne den nuværende vedligeholder og gøre pakken forældreløs, hvis vedligeholderen reagerer ikke på den forældreløse anmodning. Generelt indgiver folk kun forældreløse anmodninger, hvis de er i stand til og villige til at overtage pakken, og helst kun hvis de allerede har en fungerende strøm PKGBUILD.

I mellemtiden kan du ofte selv opdatere en forældet pakke. Ofte skal du kun ændre a PKGBUILDved at opdatere PKGVERtil det nye versionsnummer, og integritetssummer opdateres. Et program updpkgsumsfindes i pakken pacman-contrib, som automatisk beregner beløbene og opdaterer dem i PKGBUILDfor dig. Det er værd at tjekke upstreams udgivelsesbemærkninger for at se, om de nævner, at noget skal ændres under installationsprocessen af ​​den nye version. Nogle gange kræver opstrømsændringer flere ændringer eller eftersyn for at PKGBUILD/ETC. Ofte er sourcearrayet indlejret PKGVERi det, så ofte behøver det ikke engang at opdateres.