Construirea de pachete pe Arch Linux (inclusiv AUR)

• PKGBUILD
• Obținerea PKGBUILD / ETC
• Actualizarea PKGBUILD / ETC
• compilarea
• Depozitul local
• Compile mai repede
• Eroare de semnătură PGP
• Pachetele de dezvoltare AUR
• Pachetele învechite

Pe Arch Linux, depozitele oficiale sunt: ​​core, extra și comunitare. Aceste pachete sunt deja compilate și sunt instalate prin pacman. În mare parte, utilizatorii generali pot ignora faptul că aceste 3 depozite oficiale sunt separate. Core conține cele mai critice pachete, cum ar fi nucleul, procesul de pornire, rețeaua, gestionarea pachetelor, openssh ș.a. De asemenea, are cerințe mai stricte de testare mai amănunțită înainte de lansarea noilor versiuni. Extra conține alte pachete populare care nu sunt la fel de critice, cum ar fi un server X, manageri de ferestre sau browsere web. Comunitatea conține pachete mai puțin populare. Doar utilizatorii de încredere (aproximativ 60 de utilizatori activi care au fost votate de alți utilizatori de încredere) au acces pentru a face modificări în depozitele oficiale.

În 2019, există aproximativ 11.000 de pachete în depozitele oficiale, la adresa https://www.archlinux.org/packages . Dar, există multe alte programe disponibile pe Linux. Deci, AUR (Arch Linux User Repository) există, astfel încât orice utilizator Arch poate să adauge un program nou și să devină întreținătorul său, sau să adopte un pachet "orfan" fără un întreținător actual. Există aproximativ 55.000 de pachete în AUR, pe https://aur.archlinux.org/ .

Există 3 diferențe critice cu AUR:

1. Din nou, aceste pachete pot fi produse de orice utilizator, chiar unul nou.
2. AUR găzduiește doar un PKGBUILD, un script shell pentru a face automat pachetul, nu binare compilate. (Uneori, conține și mici patch-uri de text sau instalează / actualizează / dezinstalează scripturi shell). Acest lucru a făcut o treabă extraordinară permițând oricărui utilizator să contribuie, reducând în același timp șansa ca cineva să poată distribui codul rău intenționat. Comunitatea Arch este în continuare destul de utilă în privința problemelor cu pachetele AUR, dar se observă că utilizarea acestora este pe riscul dvs. Deoarece tot ceea ce oferă este un PKGBUILD, în cele din urmă este responsabilitatea dvs. de a examina o pe PKGBUILDcare o veți folosi. (Acordat, mulți utilizatori nu fac acest lucru și se bazează doar pe alții pentru a urmări.)
3. Deoarece pacmannu interacționează direct cu AUR, este responsabilitatea dvs. să actualizați pachetele AUR. Când actualizați periodic întregul dvs. sistem pacman, acesta nu va descărca automat actualizările în PKGBUILDfișierele AUR , le va compila și le va instala pentru dvs.

Deși acest articol se concentrează pe crearea de pachete din AUR, aceleași tehnici pot fi utilizate pentru a construi pachete din depozitele oficiale.

PKGBUILD

În comparație cu un .specfișier folosit de multe alte distribuții, a PKGBUILDeste un script shell scurt și simplu. Deși unele pachete sunt mai complexe, ele pot fi pur și simplu similare cu următoarele:

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
}

Acest document se referă la:

• PKGNAME: Numele unui pachet
• PKGVER: Versiunea unui pachet (care se potrivește aproape întotdeauna cu numărul versiunii din amonte)
• PKGREL: „Versiunea” arhivă a PKGBUILDunui specific PKGVER(în mod normal 1, dar incrementat dacă trebuie făcute modificări la o PKGBUILDversiune între amonte)
• ARCH: Arhitecturile pe care pachetul poate fi bazat pe (oarecum veșnic, întrucât depozitele oficiale Arch Linux acceptă doar „x86_64” (procesoare pe 64 de biți), dar pachetele AUR pot suporta în continuare „i686” (procesoare pe 32 de biți) sau „oricare” a desemna arhitectura nu are relevanță)
• PKGBUILD/ETC: Orice fișiere de fapt în depozitul AUR; a PKGBUILD, precum și orice alte patch - uri de text mici, sau să instalați / actualizare / scripturi shell de dezinstalare. Nu include fișiere în amonte în sourcetablou.

Deși AUR s-a dovedit a fi extrem de de încredere, este o idee bună să te uiți la un PKGBUILD/ETCpentru a te asigura că obține sursa dintr-un loc în care ești dispus să ai încredere; (de exemplu, o locație oficială în amonte, care poate fi din github - dar nu doar din depozitul github al unei persoane aleatoare care nu are legătură cu pachetul din amonte); și că PKGBUILD/ETCacesta nu conține niciun cod suspect.

Obținerea PKGBUILD/ETC

Din AUR

Dacă depozitele oficiale nu conțin un pachet pe care doriți să îl instalați, căutați-l la https://aur.archlinux.org/ . Sperăm că veți constata că ceea ce căutați există, este actualizat și menținut.

Cel mai bun mod de a obține PKGBUILD/ETCde la AUR este să îl clonezi prin git.

Instalați git, dacă nu este deja:

# pacman -S git

Folosiți „URL-ul Gon Clone” afișat pe site-ul AUR pentru pachetul respectiv:

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

Intrați în director și priviți conținutul acestuia. (Totul enumerat aici, cu excepția . .. .giteste PKGBUILD/ETC):

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

Dacă examinați PKGBUILD, veți vedea că utilizează codul sursă oficial din amonte și efectuează pași tipici pentru a construi un pachet, deci pare de încredere. .SRCINFOConține numai informațiile afișate pe site - ul despre pachetul, deci nu este îngrijorătoare. Dacă există alte fișiere aici, acestea nu sunt furnizate (în mod direct) de către amonte, astfel încât fișierele și modul în care sunt utilizate în acestea PKGBUILDar trebui să fie examinate, pentru a vă asigura că nu conțin nimic suspect.

Din depozitele oficiale

Deși este necesar mult mai rar, puteți construi un pachet deja în depozitele oficiale, pentru a include un patch nou, a construi o versiune mai nouă etc.

Obțineți PKGBUILD/ETCdin depozitele principale și suplimentare:

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

Din depozitul comunității:

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

Actualizarea PKGBUILD/ETC

Dacă o PKGBUILD/ETCversiune actualizată este eliberată, puteți reveni în acest director realizat folosind git cloneși actualizați-le:

$ git pull

Apoi, recompilați și actualizați pachetul folosind metoda aleasă de mai jos.

compilarea

Există multe moduri de a compila pachete. În cele din urmă, totul folosește makepkg. Există 2 moduri acceptate oficial:

• Pentru a utiliza direct makepkg, consultați https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Pentru a utiliza indirect makepkgîntr-un sistem curat chroot, consultați https://www.vultr.com/docs/using-devtools-on-arch-linux .

Există mai multe programe helper (RUA cum ar fi makepkgînvelișul), care nu sunt acceptate în mod oficial de către Arch, cum ar fi aurutils, yayși întrerupt recent tratamentul aurmanși yaourt. Chiar dacă utilizați unul dintre aceste alte programe de ajutor, vă recomandăm să vă familiarizați cu modalitățile acceptate oficial pentru a fi mai eficiente atunci când ceva nu merge bine.

Restul acestui doc va utiliza YOUR BUILDERorice metodă pe care o alegeți.

Depozitul local

Puteți configura un depozit local pentru a fi o locație centrală pentru toate pachetele pe care le construiți.

Plasați depozitul local oriunde doriți:

# mkdir /archLocalRepo

Rulați YOUR BUILDERfără opțiuni de instalare automată și copiați pachetul în depozitul local.

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

Adăugați noul pachet la indexul depozitului:

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

Pentru a elimina un pachet din indexul depozitului și fișierul pachetului în sine:

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

Dacă trebuie să înlocuiți un fișier pachet existent, trebuie să îl eliminați separat pe cel înlocuit, apoi să îl adăugați pe cel nou. Nu puteți copia noul fișier peste cel vechi.

Configurați-vă pacmanpentru a utiliza depozitul local, editând /etc/pacman.confși adăugați următoarele la sfârșit:

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

Trebuie să vă pacmanreîmprospătați cunoștințele despre depozitele (inclusiv localul dvs.), bazele de date; pentru a vedea pachetele pe care le-ați adăugat:

# pacman -Sy

Puteți instala apoi pachetul, altfel decât dacă s-ar afla într-un depozit oficial:

# pacman -S <PKGNAME>

Rețineți dacă pachetul este doar o dependență de un alt pachet pe care îl veți instala, nu trebuie să îl instalați direct. Când instalați acest alt pachet, pacmanveți găsi și instala automat pachetele de dependență în depozitul local.

Compile mai repede

În mod implicit, YOUR BUILDERcompilează utilizând un singur fir. Pe sisteme cu procesor multiplu, puteți permite să utilizați mai multe fire, atunci când este posibil. Sistemul de compilare va compila părți ale codului sursă în paralel atunci când poate. Uneori, părțile de cod necesită alte părți cu care interacționează pentru a fi deja compilate, astfel încât nu veți vedea întotdeauna câte fire de utilizare sunt permise. Editează /etc/makepkg.conf.

Pentru a permite utilizarea câtorva fire de nuclee virtuale, adăugați următoarele:

MAKEFLAGS="-j$(nproc)"

Notă: Aceasta va rula comanda de nprocfiecare dată, deci va folosi întotdeauna numărul curent de nuclee, în cazul în care actualizați serverul Vultr

Pentru a permite utilizarea mai multor nuclee virtuale, dar nu toate, de exemplu, pentru a reduce impactul la performanța generală a sistemului, adăugați un număr specific. De exemplu, dacă aveți 24 de nuclee, puteți permite 21 de utilizare:

MAKEFLAGS="-j21"

Specificând mai multe fire decât numărul de nuclee virtuale pe care le aveți va scădea performanța.

Este destul de rar, dar sistemele de compilare ale unor pachete au probleme cu compilarea paralelă, de la faptul că nu definesc corect dependențele dintre părțile de cod. În mod obișnuit, PKGBUILDfișierele acestor pachete vor gestiona acest lucru invocând make -j1, care înlocuiește valoarea implicită setată. Dacă are nevoie de acest lucru și lipsește, raportați-l la întreținătorul pachetului Arch.

Eroare de semnătură PGP

Un PKGBUILDtablou sursă poate conține .ascsau .sigfișiere. Acestea sunt adesea incluse folosind expansiunea bash brace, deci poate fi ușor de ratat:

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

Dacă unul dintre aceste formate de fișiere de semnătură sunt incluse în tabloul sursă, YOUR BUILDERîncearcă automat verificarea semnăturii arhivei sursă din amonte. Cheia PGP a semnăturii trebuie să fie în cheia utilizatorului; altfel, va anula eroarea:

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

Este important să înțelegeți că o cheie GPG poate fi afișată în mai multe moduri. Amprenta sa este de 40 de caractere hexadecimale și este ceea ce ar trebui să utilizați întotdeauna. Un cod de cheie lung este de ultimele 16 cifre, iar un cod de cheie scurtă este de ultimele 8 cifre. Deși este mai scurt este convenabil, permite duplicarea care anulează raționamentul din spatele verificării semnăturilor. Mai rău, atacatorii au fost cunoscuți că generează chei false care se potrivesc cu chei de lungime mai mică pentru dezvoltatorii de profil înalt.

Obțineți și verificați amprentele cheie PGP

Dacă nu ați încercat deja construirea pachetului, descărcați sursele care vor include fișierul de semnătură: (Dacă ați încercat construirea, acesta va fi deja acolo)

$ makepkg --nobuild --noextract

Pentru a obține amprenta completă:

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

În mod ideal, ar trebui să verificați această amprentă din amonte. Pentru a fi în siguranță, amonte ar trebui să ofere cheile de menținere ale sale undeva pe site-ul său sau în sursă. Căutarea simplă a cheii pe un server de chei nu face nimic cu adevărat. Un atacator poate trimite cu ușurință o cheie falsă, deoarece serverele cheie nu verifică autenticitatea. Cheile pot fi semnate cu alte chei, așa că dacă aveți deja o cheie în care aveți încredere, ar trebui să aveți încredere destul de sigură în orice cheie pe care au semnat-o.

Acest lucru poate fi un pic de lucru, mai ales atunci când în amonte nu publică amprenta lor sau o plasează undeva ușor de găsit. PKGBUILDVa conține o validpgpkeysmatrice, care au fost adăugate de către maintainer Arch. Dacă pachetul este un depozit oficial, asta înseamnă că un Utilizator de încredere l-a plasat acolo și ar trebui să fii destul de sigur să ai încredere doar în orice listă din tablă. Dacă pachetul este în AUR, amintiți-vă doar înseamnă că un alt utilizator Arch l-a plasat acolo. Dacă te preocupă să ai încredere în ea, poți oricând să te uiți la utilizator pentru a vedea ce au făcut în trecut cu Arch.

Adăugați cheia PGP la cheia dvs.

Pentru a adăuga amprenta la cheie:

$ gpg --recv-keys <FINGERPRINT>

Acum puteți rula YOUR BUILDERși va avea încredere în amprenta digitală.

Pachetele de dezvoltare AUR

Pachete cu nume care se termina AUR -git, -svn, -bzrsau -hgsunt versiuni de dezvoltare, care folosesc cel mai recent sistem de control al versiunii în amonte a comite în loc de Upstreams ultima versiune. De exemplu, a-gitpachetul ar folosi cea mai recentă angajare din amonte în sucursala principală (sau sucursala lor echivalentă). Acest lucru este excelent pentru a rula remedieri de erori în amonte și noi funcții care încă nu au fost lansate, și atunci când lucrați cu amonte la un bug pe care îl raportați, inclusiv dacă trebuie să verificați pentru ei, nu este o eroare care a fost rezolvată de un angajat care încă nu a fost lansat. Aceste pachete ar trebui considerate potențial instabile. Acestea fiind spuse, din păcate, uneori nu există nicio alternativă, deoarece unii întreținători din amonte nu marchează niciodată lansările sau merg excesiv de mult între lansările de etichetare și se așteaptă ca toată lumea să folosească cele mai recente angajamente. În funcție de pachet, puteți fi prima persoană care a încercat să ruleze acel angajament. În funcție de dezvoltatorii din amonte, este posibil ca ultimele lor angajamente să nu compileze,

Este important să înțelegeți o greșeală comună. Nu marcați un pachet de dezvoltare AUR ca învechit doar pentru că arată un număr de versiune veche! PKGBUILDFișierele de pachete de dezvoltare conțin o funcție suplimentară pkgver(), care este utilizată pentru a analiza automat o actualizare PKGVERdin codul sursă din amonte. Un format comun pentru un -gitpachet este <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Un pachet ar putea fi listat în AUR ca fiind 5.0.0.r102.8d7b42ac21-1, deoarece acesta PKGBUILDconține. Dar, atunci când creați un pachet, se YOUR BUILDERva actualiza automat PKGVERpentru a reflecta codul sursă recent descărcat. De fapt, în cazul în care multe versiuni noi au fost lansate, dar nu s-a schimbat nimic în procesul de construire, PKGBUILDlistarea unei versiuni vechi ar putea termina construind ceva mult mai nou, cum ar fi9.1.2.r53.2c9a41b723-1. Pentru aceste pachete, versiunea listată pe site-ul web este pur și simplu cea mai recentă versiune în momentul în care întreținătorul AUR a fost nevoit să actualizeze ultima dată PKGBUILD.

Mentenanții AUR NU trebuie să actualizeze doar PKGVERversiunile noi. Ei trebuie să facă acest lucru numai atunci când angajamentele mai noi din amonte necesită de fapt altceva în PKGBUILDschimbare.

Semnalizați un pachet de dezvoltare AUR învechit doar dacă știți că ceva nu este în regulă. Adică, ați încercat să îl utilizați și nu reușește să compileze sau să analizeze o nouă formatată corect PKGVER. Uneori se întâmplă lucruri care îl obligă pe întreținătorul AUR să actualizeze PKGBUILD, cum ar fi schimbările dependențelor din amonte, schimbarea configureopțiunilor, versiunile noi GCC preiau erori în codul sursă pe care nu le-au făcut anterior, locațiile depozitelor din amonte se schimbă sau dezvoltatorii din amonte se vor schimba acolo unde versiunea lor tipică se află în codul sursă care rup codulPKGVERfuncția de analiză. Înțelegeți că, chiar dacă nu reușește să compileze sau să funcționeze, acest lucru poate însemna întreținătorul AUR trebuie să aducă modificări procesului lor de construire, sau ar putea fi o problemă în amonte cu codul sursă de care întreținătorul AUR nu are nicio responsabilitate.

Pachetele învechite

Asigurați-vă că citiți secțiunea „Pachetele de dezvoltare AUR” de mai sus, înainte de a raporta un pachet ca fiind învechit!

Dacă în amonte a lansat o versiune mai nouă pentru un pachet non-dezvoltare decât în PKGBUILD, puteți face clic pe „Semnalați pachetul învechit” și introduceți un mesaj către întreținător. Utilizați https://packages.archlinux.org pentru pachetele oficiale de depozit și https://aur.archlinux.org pentru pachetele AUR. Un mesaj util ar fi noul număr de versiune și poate o legătură către anunțul de lansare sau codul sursă. Funcția de semnalizare trimite prin e-mail automat mesajul dvs. către întreținător.

Pe un pachet AUR, dacă după 2 săptămâni nu a existat niciun răspuns, puteți face clic pe „Trimite cerere” cu tipul „Orfan”, dacă doriți să solicitați unui utilizator de încredere să înlăture întreținerea actuală și să facă pachetul orfan, dacă întreținătorul nu răspunde la solicitarea orfanilor. În general, oamenii depun cereri orfane numai dacă sunt capabili și doresc să preia pachetul și, de preferință, numai dacă au deja un curent de lucru PKGBUILD.

Între timp, puteți actualiza adesea singur un pachet învechit. Adesea, trebuie să schimbați doar o PKGBUILDactualizare PKGVERla noul număr de versiune, iar sumele de integritate să fie actualizate. Există un program updpkgsumsîn pachet pacman-contrib, care calculează automat sumele și le actualizează în contul PKGBUILDdvs. Merită să verificați notele de versiune din amonte pentru a vedea dacă menționează că ceva trebuie schimbat în timpul procesului de instalare a noii versiuni. Uneori, modificările din amonte necesită mai multe modificări sau revizii PKGBUILD/ETC. Adesea, sourcematricea este inclusă PKGVER, așa că de multe ori nici măcar nu este nevoie de actualizare.