Ndërtimi i paketave në Arch Linux (përfshirë AUR)

Në Arch Linux, depot zyrtare janë: bërthama, shtesë dhe komuniteti. Këto paketa tashmë janë përpiluar dhe instalohen përmes pacman. Në pjesën më të madhe, përdoruesit e përgjithshëm mund të injorojnë që këto 3 depo zyrtare janë të ndara. Core përmban paketat më kritike, të tilla si kerneli, procesi i nisjes, rrjetëzimi, menaxhimi i paketave, openssh etj. Ai gjithashtu ka kërkesa më të rrepta për testim më të plotë përpara se të lëshohen versionet e reja. Extra përmban paketa të tjera të njohura që nuk janë aq kritike, të tilla si një server X, menaxherët e dritareve ose shfletuesit e uebit. Komuniteti përmban paketa më pak të njohura. Vetëm Përdoruesit e Besuar (rreth 60 përdorues aktivë të cilët janë votuar nga Përdorues të tjerë të Besuar) kanë akses për të bërë ndryshime në depot zyrtare.

Në vitin 2019, janë rreth 11,000 paketa në magazinat zyrtare, në https://www.archlinux.org/packages . Por, ka shumë programe të tjera të disponueshme në Linux. Pra, AUR (Arch Linux User Repository) ekziston kështu që çdo përdorues i Arch mund të shtojë një program të ri dhe të bëhet mirëmbajtësi i tij, ose të miratojë një paketë "jetimë" pa një mirëmbajtës aktual. Ka rreth 55,000 paketa në AUR, në https://aur.archlinux.org/ .

Ekzistojnë 3 dallime kritike me AUR:

1. Përsëri, këto paketa mund të prodhohen nga çdo përdorues, madje edhe një i ri.
2. AUR përmban vetëm një PKGBUILD, një skrip shell për të bërë automatikisht paketën, jo binarët e përpiluar. (Ndonjëherë ai gjithashtu përmban arna të vogla teksti, ose instaloni/përmirësoni/çinstaloni skriptet e guaskës). Kjo ka bërë një punë të jashtëzakonshme duke lejuar çdo përdorues të kontribuojë, ndërkohë që zbut mundësinë që dikush të jetë në gjendje të shpërndajë kodin me qëllim të keq. Komuniteti Arch është ende mjaft i dobishëm në lidhje me problemet me paketat AUR, por vihet re se përdorimi i tyre është në rrezikun tuaj. Për shkak se gjithçka që ofron është një PKGBUILD, në fund të fundit është përgjegjësia juaj të rishikoni një PKGBUILDqë do të përdorni. (Sigurisht, shumë përdorues nuk e bëjnë këtë dhe thjesht mbështeten te të tjerët për të vëzhguar.)
3. Për shkak pacmanse nuk ndërvepron drejtpërdrejt me AUR, është përgjegjësia juaj të përditësoni paketat AUR. Kur përmirësoni periodikisht të gjithë sistemin tuaj përmes pacman, ai nuk do të shkarkojë automatikisht përditësimet në PKGBUILDskedarët AUR , t'i përpilojë dhe t'i instalojë ato për ju.

Megjithëse ky artikull fokusohet në ndërtimin e paketave nga AUR, të njëjtat teknika mund të përdoren për të ndërtuar vetë paketa nga depot zyrtare.

PKGBUILD

Krahasuar me një .specskedar që përdorin shumë shpërndarje të tjera, a PKGBUILDështë një skrip i shkurtër dhe i thjeshtë shell. Megjithëse disa paketa janë më komplekse, ato thjesht mund të jenë të ngjashme me sa vijon:

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
}

Ky dokument i referohet:

• PKGNAME: Emri i një pakete
• PKGVER: Versioni i një pakete (pothuajse gjithmonë përputhet me numrin e versionit të sipërm)
• PKGREL: "Versioni" i harkut të PKGBUILDpër një specifik PKGVER(normalisht 1, por rritet nëse duhen bërë ndryshime në një PKGBUILDnga lëshimet në rrjedhën e sipërme)
• ARCH: Arkitekturat mbi të cilat mund të ndërtohet paketa (disi e trashëguar, pasi depot zyrtare të Arch Linux mbështesin vetëm "x86_64" (CPU 64-bit), por paketat AUR mund të mbështesin ende "i686" (CPU 32-bit) ose "ndonjë" përcaktimi i arkitekturës është i parëndësishëm)
• PKGBUILD/ETC: Çdo skedar aktualisht në depo AUR; të PKGBUILD, dhe çdo patches tjetër tekst të vogël, ose instaloni / upgrade / Scripts uninstall shell. Nuk përfshin skedarë në rrjedhën e sipërme në sourcegrup.

Edhe pse AUR është dëshmuar të jetë jashtëzakonisht i besueshëm, është një ide e mirë të shikoni një PKGBUILD/ETCpër t'u siguruar që po e merr burimin nga një vend ku jeni të gatshëm t'i besoni; (për shembull, një vendndodhje zyrtare në rrjedhën e sipërme, e cila mund të jetë nga github - por jo vetëm një depo github e një personi të rastësishëm që nuk ka lidhje me paketën e sipërme); dhe se PKGBUILD/ETCnuk përmban asnjë kod të dyshimtë.

Marrja PKGBUILD/ETC

Nga AUR

Nëse depot zyrtare nuk përmbajnë një paketë që po kërkoni të instaloni, kërkoni atë në https://aur.archlinux.org/ . Shpresojmë, do të zbuloni se ajo që kërkoni ekziston, është e përditësuar dhe e mirëmbajtur.

Mënyra më e mirë për të marrë PKGBUILD/ETCnga AUR është ta klononi atë nëpërmjet git.

Instaloni git, nëse nuk është tashmë:

# pacman -S git

Përdorni "URL-në Git Clone" të treguar në faqen e internetit të AUR për atë paketë:

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

Futni direktorinë dhe shikoni përmbajtjen e tij. (Gjithçka e renditur këtu, përveç se . .. .gitështë PKGBUILD/ETC):

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

Nëse shqyrtoni PKGBUILD, shpresojmë se do të shihni se përdor kodin burimor zyrtar në rrjedhën e sipërme dhe kryen hapa tipikë për të ndërtuar një paketë, kështu që duket e besueshme. .SRCINFOVetëm përmban informacionin e treguar në faqen e internetit në lidhje me paketën, kështu që nuk është shqetësuese. Nëse ka ndonjë skedar tjetër këtu, ato nuk ofrohen (drejtpërsëdrejti) nga rrjedha e sipërme, kështu që skedarët dhe mënyra se si ato përdoren në dosje PKGBUILDduhet të ekzaminohen, për t'u siguruar që nuk përmbajnë asgjë të dyshimtë.

Nga magazinat zyrtare

Megjithëse kërkohet shumë më rrallë, mund të ndërtoni një paketë tashmë në depot zyrtare, për të përfshirë një patch të ri, për të ndërtuar një version më të ri, etj.

Merrni PKGBUILD/ETCnga depot kryesore dhe shtesë:

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

Nga depoja e komunitetit:

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

Përmirësimi PKGBUILD/ETC

Nëse PKGBUILD/ETClëshohet një përditësim , mund të ktheheni në këtë direktori të krijuar duke përdorur git clonedhe t'i përditësoni ato:

$ git pull

Më pas, ripërpiloni dhe përmirësoni paketën duke përdorur metodën e zgjedhjes suaj, më poshtë.

Përpilimi

Ka shumë mënyra për të përpiluar paketa. Në fund të fundit, çdo gjë përdor makepkg. Ka 2 mënyra të mbështetura zyrtarisht:

• Për ta përdorur drejtpërdrejt makepkg, shihni https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Për ta përdorur makepkgnë mënyrë indirekte në një pastrim chroot, shihni https://www.vultr.com/docs/using-devtools-on-arch-linux .

Ka shumë programe ndihmëse AUR, (si makepkgmbështjellësi), që nuk mbështeten zyrtarisht nga Arch, si p.sh. aurutils, yay, dhe ato të ndërprera së fundi aurmandhe yaourt. Edhe nëse përdorni një nga këto programe të tjera ndihmëse, rekomandohet fuqimisht të njiheni me mënyrat e mbështetura zyrtarisht për të qenë më efektiv kur diçka nuk shkon.

Pjesa tjetër e këtij dokumenti do të përdoret YOUR BUILDERpër të nënkuptuar cilëndo metodë që ju zgjidhni.

Depoja lokale

Ju mund të konfiguroni një depo lokale që të jetë një vend qendror për të gjitha paketat që ndërtoni.

Vendosni depon lokale kudo që dëshironi:

# mkdir /archLocalRepo

Ekzekutoni YOUR BUILDERpa asnjë opsion instalimi automatik dhe kopjoni paketën në depon tuaj lokale.

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

Shtoni paketën e re në indeksin e depove:

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

Për të hequr një paketë nga indeksi i depove dhe vetë skedari i paketës:

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

Nëse keni nevojë të zëvendësoni një skedar ekzistues pakete, duhet të hiqni veçmas atë që zëvendësohet dhe më pas të shtoni të riun. Ju nuk mund të kopjoni thjesht skedarin e ri mbi atë të vjetër.

Konfiguro pacmanpër të përdorur depon tuaj lokale, duke redaktuar /etc/pacman.conf, dhe shtoni sa vijon në fund:

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

Ju duhet të pacmanrifreskoni njohuritë e tij për depo, (përfshirë atë tuaj lokale), bazat e të dhënave; për të parë paketat që keni shtuar në të:

# pacman -Sy

Më pas mund ta instaloni paketën, jo ndryshe nga sa ishte në një depo zyrtare:

# pacman -S <PKGNAME>

Vini re nëse paketa është thjesht një varësi e një pakete tjetër që do të instaloni, nuk keni nevojë ta instaloni drejtpërdrejt. Kur instaloni këtë paketë tjetër, pacmanautomatikisht do të gjeni dhe instaloni paketat e varësisë në depon tuaj lokale.

Përpiloni më shpejt

Si parazgjedhje, YOUR BUILDERpërpilohet duke përdorur një fill të vetëm. Në sistemet me shumë CPU, ju mund të lejoni përdorimin e fijeve të shumta kur është e mundur. Sistemi i ndërtimit do të përpilojë pjesë të kodit burimor paralelisht kur të jetë e mundur. Ndonjëherë pjesët e kodit kërkojnë që pjesët e tjera me të cilat ndërvepron tashmë të kompilohen, kështu që nuk do të shihni gjithmonë të përdoren aq thread sa lejohen. Redakto /etc/makepkg.conf.

Për të lejuar përdorimin e aq threads sa keni bërthama virtuale, shtoni sa vijon:

MAKEFLAGS="-j$(nproc)"

Shënim: Kjo do të ekzekutojë komandën nprocçdo herë, kështu që gjithmonë do të përdorë numrin aktual të bërthamave, në rast se përmirësoni serverin tuaj Vultr

Për të lejuar përdorimin e bërthamave të shumta virtuale, por jo të gjitha, si për të reduktuar ndikimin në performancën e përgjithshme të sistemit, shtoni një numër specifik. Për shembull, nëse keni 24 bërthama, mund të lejoni përdorimin e 21:

MAKEFLAGS="-j21"

Specifikimi i më shumë threads se numri i bërthamave virtuale që keni do të ulë performancën.

Është mjaft e rrallë, por disa sisteme të ndërtimit të paketave kanë probleme me kompilimin paralel, nga mospërcaktimi i duhur i varësive midis pjesëve të kodit. Në mënyrë tipike, PKGBUILDskedarët e atyre paketave do ta trajtojnë këtë për ju duke thirrur make -j1, e cila anulon parazgjedhjen që keni vendosur. Nëse ka nevojë për këtë dhe mungon, raportojeni te mirëmbajtësi i paketës Arch.

Gabim nënshkrimi PGP

Një PKGBUILDgrup burimi mund të përmbajë .ascose .sigskedarë. Ato shpesh përfshihen duke përdorur zgjerimin e mbajtësit bash, kështu që mund të jetë e lehtë për t'u humbur:

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

Nëse njëri prej këtyre formateve të skedarëve të nënshkrimit përfshihet në grupin burimor, YOUR BUILDERautomatikisht përpiqet të verifikojë nënshkrimin e arkivit të burimit në rrjedhën e sipërme. Çelësi PGP i nënshkrimit duhet të jetë në çelësin e përdoruesit; përndryshe, do të ndërpritet me gabimin:

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

Është e rëndësishme të kuptoni se një çelës GPG mund të tregohet në disa mënyra. Gjurma e gishtit është 40 karaktere heksadecimal dhe është ajo që duhet të përdorni gjithmonë. Një ID e çelësit të gjatë është 16 shifrat e fundit dhe një ID e shkurtër e çelësit është 8 shifrat e fundit. Edhe pse më e shkurtra është e përshtatshme, ajo lejon dublikatat që anulojnë të gjithë arsyetimin pas verifikimit të nënshkrimeve. Më keq, sulmuesit kanë qenë të njohur për gjenerimin e çelësave të rremë që përputhen me çelësat me gjatësi më të vogël për zhvilluesit e profilit të lartë.

Merrni dhe verifikoni gjurmën e gishtit të çelësit PGP

Nëse nuk e keni provuar tashmë ndërtimin e paketës, shkarkoni burimet që do të përfshijnë skedarin e nënshkrimit: (Nëse keni provuar ndërtimin, ai tashmë do të jetë atje)

$ makepkg --nobuild --noextract

Për të marrë gjurmën e plotë të gishtit:

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

Në mënyrë ideale, duhet ta verifikoni këtë gjurmë gishti nga rrjedha e sipërme. Për të qenë i sigurt, në rrjedhën e sipërme duhet t'i japë çelësat e mirëmbajtësve të tij diku në faqen e tij të internetit ose në burim. Thjesht kërkimi i çelësit në një server kyç nuk është në të vërtetë duke bërë asgjë. Një sulmues mund të paraqesë lehtësisht një çelës të rremë, sepse serverët kryesorë nuk e verifikojnë vërtetësinë. Çelësat mund të nënshkruhen nga çelësa të tjerë, kështu që nëse tashmë keni një çelës të cilit i besoni, duhet të jeni mjaft të sigurt duke besuar çdo çelës që ata kanë nënshkruar.

Kjo mund të jetë shumë punë, veçanërisht kur në rrjedhën e sipërme nuk e publikon gjurmën e gishtit ose nuk e vendos atë diku të lehtë për t'u gjetur. PKGBUILDDo të përmbajë një validpgpkeysrrjet, të cilat janë shtuar nga mirëmbajtësi Arch. Nëse paketa është një depo zyrtare, kjo do të thotë që një Përdorues i Besuar e vendos atë atje dhe ju duhet të jeni mjaft të sigurt për të besuar vetëm çdo gjë të listuar në grup. Nëse paketa është në AUR, mbani mend se thjesht do të thotë që një përdorues tjetër i Arch e vendosi atë atje. Nëse jeni të shqetësuar për besimin në të, gjithmonë mund të shikoni përdoruesin për të parë se çfarë ka bërë në të kaluarën me Arch.

Shtoni çelësin PGP në çelësin tuaj

Për të shtuar gjurmën e gishtit në çelësin tuaj:

$ gpg --recv-keys <FINGERPRINT>

Tani mund të ekzekutosh YOUR BUILDERdhe do t'i besojë gjurmës së gishtit.

Paketat Zhvillimore AUR

Paketa AUR me emra duke i dhënë fund -git, -svn, -bzrose -hgversione zhvillimore, të cilat përdorin sistemin e fundit në rrjedhën e sipërme të mirë të kontrollit të kryer në vend në rrjedhën e sipërme është publikimin e fundit. Për shembull, a-gitpaketa do të përdorte kryerjen më të fundit të rrjedhës së sipërme në degën kryesore (ose degën ekuivalente të tyre.) Kjo është e shkëlqyeshme për ekzekutimin e korrigjimeve të gabimeve në rrjedhën e sipërme dhe veçorive të reja që nuk janë lëshuar ende, dhe kur punoni me rrjedhën e sipërme në një defekt që po raportoni, duke përfshirë nëse ju duhet të verifikoni për ta se nuk është një gabim që është rregulluar nga një commit që nuk është ende në një version. Këto paketa duhet të konsiderohen potencialisht të paqëndrueshme. Thënë kjo, për fat të keq, ndonjëherë nuk ka alternativë sepse disa mirëmbajtës në rrjedhën e sipërme nuk etiketojnë kurrë publikimet ose kalojnë shumë gjatë ndërmjet publikimeve të etiketimit dhe presin që të gjithë të përdorin kryerjen e tyre më të fundit. Në varësi të paketës, mund të jeni personi i parë që provoni ta ekzekutoni atë commit. Në varësi të zhvilluesve në rrjedhën e sipërme, angazhimi i tyre i fundit mund të mos përpilohet,

Është e rëndësishme të kuptoni një gabim të zakonshëm. Mos e shënoni një paketë zhvillimore AUR si të vjetëruar thjesht sepse tregon një numër versioni të vjetër! PKGBUILDSkedarët e paketave zhvillimore përmbajnë një funksion shtesë pkgver(), i cili përdoret për të analizuar automatikisht një të përditësuar PKGVERnga kodi burimor i rrjedhës së sipërme. Një format i zakonshëm për një -gitpaketë është <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Një paketë mund të renditet në AUR si 5.0.0.r102.8d7b42ac21-1, sepse kjo është ajo që PKGBUILDpërmban. Por, kur krijoni një paketë, YOUR BUILDERdo të përditësohet automatikisht PKGVERpër të pasqyruar kodin burimor të sapo shkarkuar. Në fakt, nëse janë lëshuar shumë versione të reja, por asgjë nuk ka ndryshuar në procesin e ndërtimit, një PKGBUILDrenditje e tillë e një versioni të vjetër mund të përfundojë ndërtimin e diçkaje shumë më të re, si p.sh.9.1.2.r53.2c9a41b723-1. Për këto paketa, versioni i listuar në faqen e internetit është thjesht versioni më i fundit në kohën kur mbajtësi i AUR-it iu desh për herë të fundit të përditësonte PKGBUILD.

Mbajtësit AUR NUK supozohet të përditësojnë vetëm PKGVERpër të pasqyruar versionet e reja. Ata supozohet ta bëjnë këtë vetëm kur kryerjet më të reja në rrjedhën e sipërme kërkojnë në të vërtetë diçka tjetër PKGBUILDpër të ndryshuar.

Shënoni vetëm një paketë zhvillimore AUR të vjetëruar nëse e dini se diçka nuk është në të vërtetë. Do të thotë, në fakt ju keni provuar ta përdorni dhe ai dështon në përpilimin ose analizimin e një të reje të formatuar siç duhet PKGVER. Ndonjëherë ndodhin gjëra që detyrojnë mbajtësin e AUR të përditësojë PKGBUILD, si p.sh. ndryshojnë varësitë në rrjedhën e sipërme, ndryshojnë configureopsionet, versionet e reja të GCC marrin gabime në kodin burimor që nuk kanë bërë ato të mëparshmet, vendndodhjet e depozitave në rrjedhën e sipërme ndryshojnë ose zhvilluesit në rrjedhën e sipërme do të ndryshojnë ku versioni i tyre tipik është brenda kodit burimor duke thyerPKGVERfunksioni i analizimit. Kuptoni se edhe nëse dështon në kompilimin ose funksionimin, kjo mund të nënkuptojë ose që mirëmbajtësi i AUR duhet të bëjë ndryshime në procesin e tij të ndërtimit, ose mund të jetë një problem në rrjedhën e sipërme me kodin e tij burimor për të cilin mbajtësi i AUR nuk ka përgjegjësi.

Paketat e vjetruara

Sigurohuni që të lexoni seksionin "Paketat Zhvillimore AUR" më sipër, përpara se të raportoni një paketë si të vjetëruar!

Nëse në rrjedhën e sipërme ka lëshuar një version më të ri për një paketë jo-zhvilluese sesa në PKGBUILD, mund të klikoni "Flamuri i paketës së vjetër" dhe t'i shkruani një mesazh mbajtësit. Përdorni https://packages.archlinux.org për paketat zyrtare të depove dhe https://aur.archlinux.org për paketat AUR. Një mesazh i dobishëm do të ishte numri i versionit të ri, dhe ndoshta një lidhje me njoftimin e lëshimit ose kodin burimor. Funksioni i raportimit i dërgon automatikisht mesazhin tuaj mbajtësit me email.

Në një paketë AUR, nëse nuk ka pasur përgjigje pas 2 javësh, mund të klikoni "Dërgo kërkesën" me llojin "Jetim", nëse dëshironi të kërkoni nga një përdorues i besuar të heqë mirëmbajtesin aktual dhe ta bëjë paketën jetime, nëse mirëmbajtësi nuk i përgjigjet kërkesës së jetimit. Në përgjithësi, njerëzit paraqesin kërkesa jetimë vetëm nëse janë në gjendje dhe dëshirojnë të marrin përsipër paketën, dhe mundësisht vetëm nëse kanë tashmë një rrymë funksionale PKGBUILD.

Ndërkohë, shpesh mund të përditësoni vetë një paketë të vjetëruar. Shpesh ju duhet vetëm të ndryshoni a PKGBUILDduke përditësuar numrin PKGVERnë versionin e ri dhe shumat e integritetit të përditësohen. Ekziston një program updpkgsumsnë paketën pacman-contrib, i cili automatikisht llogarit shumat dhe i përditëson ato në PKGBUILDpër ju. Vlen të kontrolloni shënimet e lëshimit të rrjedhës së sipërme, për të parë nëse përmendin se diçka duhet të ndryshojë gjatë procesit të instalimit të versionit të ri. Ndonjëherë ndryshimet në rrjedhën e sipërme kërkojnë më shumë ndryshime ose rregullime të PKGBUILD/ETC. Shpesh sourcegrupi futet PKGVERnë të, kështu që shpesh nuk ka nevojë as për përditësim.