Bygge pakker på Arch Linux (inkludert AUR)

På Arch Linux er de offisielle depotene: kjerne, ekstra og fellesskap. Disse pakkene er allerede kompilert, og de er installert gjennom pacman. For det meste kan generelle brukere ignorere at disse 3 offisielle depotene er separate. Core inneholder de mest kritiske pakkene, som kjernen, oppstartsprosessen, nettverk, pakkehåndtering, openssh og så videre. Den har også strengere krav til grundigere testing før nye versjoner slippes. Extra inneholder andre populære pakker som ikke er like kritiske, for eksempel en X-server, vindusbehandlere eller nettlesere. Fellesskapet inneholder mindre populære pakker. Bare pålitelige brukere (ca. 60 aktive brukere som ble stemt på av andre klarerte brukere) har tilgang til å gjøre endringer i de offisielle lagrene.

I 2019 er det omtrent 11 000 pakker i de offisielle depotene, på https://www.archlinux.org/packages . Men det er mange andre programmer tilgjengelig på Linux. Så AUR (Arch Linux User Repository) eksisterer slik at enhver Arch-bruker kan legge til et nytt program og bli dets vedlikeholder, eller ta i bruk en "foreldreløs" pakke uten en nåværende vedlikeholder. Det er omtrent 55 000 pakker i AUR, på https://aur.archlinux.org/ .

Det er 3 kritiske forskjeller med AUR:

1. Igjen, disse pakkene kan produseres av enhver bruker, til og med en helt ny.
2. AUR-en inneholder bare et PKGBUILD, et skall-skript for automatisk å lage pakken, ikke kompilerte binære filer. (Noen ganger inneholder den også små tekstoppdateringer, eller installer/oppgrader/avinstaller shell-skript). Dette har gjort en enorm jobb som lar enhver bruker bidra, samtidig som det reduserer sjansen for at noen kan distribuere ondsinnet kode. Arch-fellesskapet er fortsatt ganske nyttig når det gjelder problemer med AUR-pakker, men det bemerkes at bruken av dem er på egen risiko. Fordi alt det gir er en PKGBUILD, er det til syvende og sist ditt ansvar å vurdere en PKGBUILDdu skal bruke. (Riktignok gjør mange brukere ikke dette og stoler bare på at andre følger med.)
3. Fordi pacmandet ikke samhandler direkte med AUR, er det ditt ansvar å oppdatere AUR-pakker. Når du periodisk oppgraderer hele systemet gjennom pacman, vil det ikke automatisk laste ned oppdateringer til AUR- PKGBUILDfiler, kompilere dem og installere dem for deg.

Selv om denne artikkelen fokuserer på å bygge pakker fra AUR, kan de samme teknikkene brukes til å bygge pakker fra de offisielle depotene selv.

PKGBUILD

Sammenlignet med en .specfil som mange andre distribusjoner bruker, PKGBUILDer a et kort og enkelt skallskript. Selv om noen pakker er mer komplekse, kan de ganske enkelt ligne på 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 dokumentet viser til:

• PKGNAME: Navnet på en pakke
• PKGVER: Versjonen av en pakke (matcher nesten alltid oppstrøms versjonsnummer)
• PKGREL: Arch "versjonen" av PKGBUILDfor en spesifikk PKGVER(normalt 1, men økes hvis endringer må gjøres i en PKGBUILDmellom oppstrøms utgivelser)
• ARCH: Arkitekturene pakken kan bygges på (noe eldre, ettersom Arch Linux offisielle repositorier bare støtter "x86_64" (64-bits CPUer), men AUR-pakker kan fortsatt støtte "i686" (32-bits CPUer) eller "hvilken som helst" å utpeke arkitektur er irrelevant)
• PKGBUILD/ETC: Alle filer som faktisk er i AUR-depotet; de PKGBUILDog alle andre små tekst patcher, eller installere / oppgradere / avinstallere skallskript. Inkluderer ikke oppstrømsfiler i sourcearrayet.

Selv om AUR har vist seg å være ekstremt pålitelig, er det en god idé å se på en for PKGBUILD/ETCå sikre at den får kilden fra et sted du er villig til å stole på; (for eksempel en offisiell oppstrøms plassering, som kan være fra github - men ikke bare en tilfeldig persons github-lager som ikke er relatert til oppstrømspakken); og at den PKGBUILD/ETCikke inneholder noen mistenkt kode.

Å skaffe seg PKGBUILD/ETC

Fra AUR

Hvis de offisielle depotene ikke inneholder en pakke du ønsker å installere, søk etter den på https://aur.archlinux.org/ . Forhåpentligvis vil du finne at det du leter etter eksisterer, er oppdatert og vedlikeholdt.

Den beste måten å få tak i PKGBUILD/ETCfra AUR er å klone den via git.

Installer git, hvis det ikke allerede er:

# pacman -S git

Bruk "Git Clone URL" vist på AUR-nettstedet for den pakken:

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

Gå inn i katalogen og se på innholdet. (Alt oppført her, bortsett fra . .. .giter PKGBUILD/ETC):

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

Hvis du undersøker PKGBUILD, vil du forhåpentligvis se at den bruker den offisielle oppstrømskildekoden og utfører typiske trinn for å bygge en pakke, så den virker pålitelig. Den .SRCINFOinneholder bare informasjonen som vises på nettstedet om pakken, så det er ikke bekymringsfullt. Hvis det er andre filer her, er de ikke (direkte) levert av upstream, så filene og hvordan de brukes i filen PKGBUILDbør undersøkes for å sikre at de ikke inneholder noe mistenkt.

Fra offisielle arkiver

Selv om det kreves mye sjeldnere, kan du bygge en pakke allerede i de offisielle depotene, for å inkludere en ny oppdatering, bygge en nyere versjon, etc.

Få PKGBUILD/ETCfra kjernen og ekstra depoter:

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

Fra fellesskapsdepotet:

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

Oppgradering PKGBUILD/ETC

Hvis en oppgradert PKGBUILD/ETCer utgitt, kan du komme tilbake til denne katalogen som er laget med git clone, og oppdatere dem:

$ git pull

Deretter kan du kompilere og oppgradere pakken på nytt ved å bruke metoden du velger, nedenfor.

Kompilere

Det er mange måter å kompilere pakker på. Til syvende og sist bruker alt makepkg. Det er 2 offisielt støttede måter:

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

Det er mange AUR-hjelpeprogrammer (som makepkgwrapperen), som ikke offisielt støttes av Arch, som aurutils, yay, og den nylig avviklede aurmanog yaourt. Selv om du bruker et av disse andre hjelpeprogrammene, anbefales det på det sterkeste å bli kjent med de offisielt støttede måtene for å bli mer effektiv når noe går galt.

Resten av dette dokumentet vil bruke YOUR BUILDERtil å bety hvilken metode du enn velger.

Lokalt depot

Du kan sette opp et lokalt depot for å være et sentralt sted for alle pakkene du bygger.

Plasser det lokale depotet der du vil:

# mkdir /archLocalRepo

Kjør YOUR BUILDERuten noen automatiske installasjonsalternativer, og kopier pakken til ditt lokale depot.

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

Legg til den nye pakken til depotindeksen:

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

Slik fjerner du en pakke fra depotets indeks og selve pakkefilen:

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

Hvis du trenger å erstatte en eksisterende pakkefil, må du fjerne den som erstattes separat, og deretter legge til den nye. Du kan ikke bare kopiere den nye filen over den gamle.

Konfigurer for pacmanå bruke ditt lokale depot ved å redigere /etc/pacman.conf, og legg til følgende på slutten:

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

Du må ha pacmanoppfrisket kunnskapen om depotdatabaser (inkludert din lokale), databaser; for å se pakker du har lagt til:

# pacman -Sy

Du kan deretter installere pakken, ikke annerledes enn om den var i et offisielt depot:

# pacman -S <PKGNAME>

Merk at hvis pakken bare er en avhengighet av en annen pakke du skal installere, trenger du ikke installere den direkte. Når du installerer denne andre pakken, pacmanvil automatisk finne og installere avhengighetspakkene i ditt lokale depot.

Kompiler raskere

Kompilerer som standard YOUR BUILDERved hjelp av en enkelt tråd. På multi CPU-systemer kan du tillate bruk av flere tråder der det er mulig. Byggesystemet vil kompilere deler av kildekoden parallelt når det kan. Noen ganger krever deler av koden at andre deler den samhandler med allerede er kompilert, så du vil ikke alltid se så mange tråder som brukes som er tillatt. Rediger /etc/makepkg.conf.

For å tillate bruk av så mange tråder som du har virtuelle kjerner, legg til følgende:

MAKEFLAGS="-j$(nproc)"

Merk: Dette vil kjøre kommandoen nprochver gang, så det vil alltid bruke gjeldende antall kjerner, i tilfelle du oppgraderer Vultr-serveren din

For å tillate bruk av flere virtuelle kjerner, men ikke alle, for eksempel for å redusere innvirkningen på den generelle systemytelsen, legg til et spesifikt tall. For eksempel, hvis du har 24 kjerner, kan du tillate at 21 brukes:

MAKEFLAGS="-j21"

Hvis du spesifiserer flere tråder enn antallet virtuelle kjerner du har, reduseres ytelsen.

Det er ganske sjeldent, men enkelte pakkers byggesystemer har problemer med parallell kompilering, fra å ikke definere avhengigheter mellom deler av koden ordentlig. Vanligvis vil disse pakkenes PKGBUILDfiler håndtere dette for deg ved å påkalle make -j1, som overstyrer standarden du angir. Hvis det trenger dette og det mangler, rapporter det til Arch-pakkens vedlikeholder.

PGP-signaturfeil

En PKGBUILDkildematrise kan inneholde .asceller .sigfiler. De er ofte inkludert ved bruk av bash brace-utvidelse, så det kan være lett å gå glipp av:

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

Hvis et av disse formatene for signaturfiler er inkludert i kildematrisen, YOUR BUILDERforsøker det automatisk å bekrefte oppstrømskildearkivets signatur. Signaturens PGP-nøkkel må være i brukerens nøkkelring; ellers vil den avbryte med feilen:

==> 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 viktig å forstå at en GPG-nøkkel kan vises på flere måter. Fingeravtrykket er på 40 heksadesimale tegn, og er det du alltid bør bruke. En lang nøkkel-ID er de siste 16 sifrene, og en kort nøkkel-ID er de siste 8 sifrene. Selv om kortere er praktisk, tillater det duplikater som ugyldiggjør hele resonnementet bak verifisering av signaturer. Enda verre, angripere har vært kjent for å generere falske nøkler som matcher nøkler med mindre lengde for høyt profilerte utviklere.

Skaff og verifiser PGP-nøkkel-fingeravtrykk

Hvis du ikke har prøvd å bygge pakken allerede, last ned kildene som inkluderer signaturfilen: (Hvis du prøvde å bygge, vil den allerede være der)

$ makepkg --nobuild --noextract

Slik får du hele fingeravtrykket:

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

Ideelt sett bør du verifisere dette fingeravtrykket fra oppstrøms. For å være sikker, bør oppstrøms gi vedlikeholdernes nøkler et sted på nettstedet eller i kilden. Bare å søke etter nøkkelen på en nøkkelserver gjør egentlig ingenting. En angriper kan enkelt sende inn en falsk nøkkel, fordi nøkkelservere ikke bekrefter ektheten. Nøkler kan signeres av andre nøkler, så hvis du allerede har en nøkkel du stoler på, bør du være ganske trygg på å stole på alle nøkler de har signert.

Det kan være ganske mye arbeid, spesielt når upstream ikke publiserer fingeravtrykket sitt eller plasserer det et sted som er lett å finne. Den PKGBUILDvil inneholde en validpgpkeysmatrise, som ble lagt til av Arch-vedlikeholderen. Hvis pakken er et offisielt oppbevaringssted, betyr det at en pålitelig bruker har plassert den der, og du bør være ganske trygg på å stole på alt som er oppført i arrayet. Hvis pakken er i AUR, husk at det bare betyr at en annen Arch-bruker plasserte den der. Hvis du er bekymret for å stole på den, kan du alltid se på brukeren for å se hva de har gjort tidligere med Arch.

Legg til PGP-nøkkel til nøkkelringen

Slik legger du til fingeravtrykket til nøkkelringen:

$ gpg --recv-keys <FINGERPRINT>

Du kan nå kjøre YOUR BUILDER, og den vil stole på fingeravtrykket.

AUR utviklingspakker

AUR pakker med navn som slutter -git, -svn, -bzreller -hger utviklingsversjoner, som bruker oppstrøms nyeste versjonskontrollsystem begå stedet for oppstrøms nyeste utgivelse. For eksempel, en-gitpakken vil bruke oppstrøms siste commit i mastergrenen (eller tilsvarende gren.) Dette er flott for å kjøre oppstrøms feilrettinger og nye funksjoner som ikke er utgitt ennå, og når du arbeider med oppstrøms på en feil du rapporterer, inkludert hvis du må bekrefte for dem at det ikke er en feil som er fikset av en commit som ennå ikke er i en utgivelse. Disse pakkene bør betraktes som potensielt ustabile. Når det er sagt, dessverre, noen ganger er det ikke noe alternativ fordi noen oppstrøms vedlikeholdere aldri merker utgivelser eller går for lang tid mellom tagging av utgivelser, og forventer at alle bruker sin siste forpliktelse. Avhengig av pakken, kan du være den første personen som prøver å kjøre den forpliktelsen. Avhengig av oppstrømsutviklerne, kan det hende at deres siste forpliktelse ikke engang kompileres,

Det er viktig å forstå en vanlig feil. Ikke flagg en AUR-utviklingspakke som utdatert bare fordi den viser et gammelt versjonsnummer! Utviklingspakkefiler PKGBUILDinneholder en tilleggsfunksjon pkgver(), som brukes til å automatisk analysere en oppdatert PKGVERfra oppstrøms kildekode. Et vanlig format for en -gitpakke er <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. En pakke kan være oppført i AUR som 5.0.0.r102.8d7b42ac21-1, fordi det er det den PKGBUILDinneholder. Men når du oppretter en pakke, YOUR BUILDERoppdateres den automatisk for PKGVERå gjenspeile den nylig nedlastede kildekoden. Faktisk, hvis mange nye versjoner har blitt utgitt, men ingenting har endret seg i byggeprosessen, kan en slik PKGBUILDoppføring av en gammel versjon ende opp med å bygge noe mye nyere, som f.eks.9.1.2.r53.2c9a41b723-1. For disse pakkene er versjonen som er oppført på nettstedet ganske enkelt den nyeste versjonen på det tidspunktet AUR-vedlikeholderen sist måtte oppdatere PKGBUILD.

AUR-vedlikeholdere skal IKKE bare oppdatere for PKGVERå gjenspeile nye versjoner. De er bare ment å gjøre det når nyere oppstrøms forpliktelser faktisk krever noe annet i PKGBUILDå endre.

Merk kun en utviklingsmessig AUR-pakke som er utdatert hvis du vet at noe faktisk er galt. Det betyr at du faktisk har prøvd å bruke den, og den mislykkes med å kompilere eller analysere en riktig formatert ny PKGVER. Noen ganger skjer det ting som tvinger AUR-vedlikeholderen til å oppdatere PKGBUILD, som oppstrøms avhengigheter endres, configurealternativer endres, nye GCC-versjoner fanger opp feil i kildekoden som tidligere ikke gjorde, oppstrøms depotplasseringer endres eller oppstrømsutviklere vil endre hvor deres typiske versjon er innenfor kildekoden bryterPKGVERparsing funksjon. Forstå at selv om det mislykkes med kompilering eller fungerer, kan dette enten bety at AUR-vedlikeholderen må gjøre endringer i byggeprosessen, eller det kan være et oppstrømsproblem med kildekoden som AUR-vedlikeholderen ikke har noe ansvar for.

Utdaterte pakker

Sørg for å lese avsnittet "AUR Developmental Packages" ovenfor før du rapporterer en pakke som utdatert!

Hvis upstream har gitt ut en nyere versjon for en ikke-utviklingspakke enn i PKGBUILD, kan du klikke "Flagg pakke utdatert" og skrive en melding til vedlikeholderen. Bruk https://packages.archlinux.org for offisielle repository-pakker, og https://aur.archlinux.org for AUR-pakker. En nyttig melding vil være det nye versjonsnummeret, og kanskje en lenke til utgivelseskunngjøringen eller kildekoden. Flaggingsfunksjonen sender automatisk e-posten din til vedlikeholderen.

På en AUR-pakke, hvis det ikke har kommet noe svar etter 2 uker, kan du klikke på "Send forespørsel" med typen "Orphan", hvis du vil be en pålitelig bruker om å fjerne gjeldende vedlikeholder, og gjøre pakken foreldreløs, hvis vedlikeholderen svarer ikke på den foreldreløse forespørselen. Vanligvis sender folk bare foreldreløse forespørsler hvis de er i stand til og villige til å overta pakken, og helst bare hvis de allerede har en fungerende strøm PKGBUILD.

I mellomtiden kan du ofte oppdatere en utdatert pakke selv. Ofte trenger du bare å endre a PKGBUILDved å oppdatere PKGVERtil det nye versjonsnummeret, og integritetssummer oppdateres. Et program updpkgsumsfinnes i pakken pacman-contrib, som automatisk beregner summene og oppdaterer dem i PKGBUILDfor deg. Det er verdt å sjekke oppstrøms utgivelsesnotater for å se om de nevner at noe må endres under installasjonsprosessen av den nye versjonen. Noen ganger krever oppstrømsendringer flere endringer eller overhalinger for å PKGBUILD/ETC. Ofte er sourcearrayet innebygd PKGVERi det, så ofte trenger det ikke engang å oppdateres.