Csomagok építése Arch Linuxon (beleértve az AUR-t is)

Arch Linuxon a hivatalos adattárak a következők: core, extra és közösségi. Ezek a csomagok már le vannak fordítva, és telepítésük a következőn keresztül történik pacman. Az általános felhasználók többnyire figyelmen kívül hagyhatják, hogy ez a 3 hivatalos adattár különálló. A Core tartalmazza a legkritikusabb csomagokat, mint például a kernel, a rendszerindítási folyamat, a hálózat, a csomagkezelés, az openssh és így tovább. Ezenkívül szigorúbb követelményeket támaszt az alaposabb teszteléssel az új verziók megjelenése előtt. Az Extra más népszerű csomagokat is tartalmaz, amelyek nem olyan kritikusak, mint például az X szerver, az ablakkezelők vagy a webböngészők. A közösség kevésbé népszerű csomagokat tartalmaz. Csak a Megbízható Felhasználók (körülbelül 60 aktív felhasználó, akikre más megbízható felhasználók szavaztak) férhetnek hozzá a hivatalos adattárak módosításához.

2019-ben körülbelül 11 000 csomag található a hivatalos tárolókban, a https://www.archlinux.org/packages címen . De sok más program is elérhető Linuxon. Tehát az AUR (Arch Linux User Repository) létezik, így bármely Arch felhasználó hozzáadhat egy új programot, és karbantartója lehet, vagy elfogadhat egy „árva” csomagot jelenlegi karbantartó nélkül. Az AUR-ban körülbelül 55 000 csomag található a https://aur.archlinux.org/ címen .

Három lényeges különbség van az AUR-tól:

1. Ezeket a csomagokat ismételten bármilyen felhasználó elkészítheti, akár vadonatújat is.
2. Az AUR csak PKGBUILDegy shell szkriptet tartalmaz, amely automatikusan létrehozza a csomagot, nem pedig lefordított binárisokat. (Néha kis szövegfoltokat, vagy telepítő/frissítő/eltávolító shell szkripteket is tartalmaz). Ez óriási munkát végzett, lehetővé téve bármely felhasználó számára, hogy hozzájáruljon, miközben csökkenti annak esélyét, hogy valaki rosszindulatú kódot terjeszthessen. Az Arch közösség továbbra is nagyon segítőkész az AUR csomagokkal kapcsolatos problémákban, de meg kell jegyezni, hogy a használatuk saját felelősségére történik. Mivel csak egy PKGBUILD, az Ön felelőssége, hogy felülvizsgálja a PKGBUILDhasználni kívánt elemet. (Bizony, sok felhasználó nem teszi ezt, és csak másokra hagyatkozik, hogy figyeljenek.)
3. Mivel pacmannem kapcsolódik közvetlenül az AUR-hoz, az Ön felelőssége az AUR-csomagok frissítése. Ha rendszeres időközönként frissíti a teljes rendszert a következőn keresztül pacman, akkor az nem tölti le automatikusan az AUR- PKGBUILDfájlok frissítéseit, nem fordítja le és telepíti azokat Ön helyett.

Bár ez a cikk a csomagok AUR-ból való összeállítására összpontosít, ugyanezeket a technikákat használhatja csomagok létrehozására a hivatalos adattárakból.

PKGBUILD

A .specsok más disztribúció által használt fájlhoz képest az a PKGBUILDegy rövid és egyszerű shell szkript. Bár egyes csomagok összetettebbek, egyszerűen hasonlíthatnak a következőkhöz:

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
}

Ez a dokumentum a következőkre vonatkozik:

• PKGNAME: Egy csomag neve
• PKGVER: A csomag verziója (majdnem mindig megegyezik az upstream verziószámával)
• PKGREL: Az Arch "verziója" PKGBUILDegy adott PKGVERadottsághoz (általában 1, de növelve, ha módosítani kell az a-t PKGBUILDaz upstream kiadások között)
• ARCH: Az architektúrák, amelyekre a csomag építhető (némileg örökölt, mivel az Arch Linux hivatalos tárolói csak az "x86_64" (64 bites CPU-kat) támogatják, de az AUR csomagok továbbra is támogathatják az "i686" (32 bites CPU) vagy "bármelyik" az építészet megjelölése irreleváns)
• PKGBUILD/ETC: Bármely fájl, amely ténylegesen az AUR tárolóban van; a PKGBUILD, és minden más kis szövegfoltot, vagy telepítse/frissítse/eltávolítsa a shell szkripteket. Nem tartalmaz upstream fájlokat a sourcetömbben.

Bár az AUR rendkívül megbízhatónak bizonyult, érdemes megnézni egy PKGBUILD/ETC, hogy megbizonyosodjon arról, hogy olyan helyről szerzi a forrást, amelyben hajlandó megbízni; (például egy hivatalos upstream hely, amely lehet a githubból – de nem csak egy véletlenszerű személy github tárházából, aki nem kapcsolódik az upstream csomaghoz); és hogy az PKGBUILD/ETCnem tartalmaz gyanús kódot.

Megszerzése PKGBUILD/ETC

Az AUR-ból

Ha a hivatalos adattárak nem tartalmaznak olyan csomagot, amelyet telepíteni szeretne, keresse meg a https://aur.archlinux.org/ oldalon . Remélhetőleg azt fogja tapasztalni, hogy amit keres, az létezik, naprakész és karbantartott.

Az PKGBUILD/ETCAUR-ból a legjobb módszer az, ha klónozzuk a segítségével git.

Telepítse git, ha még nincs:

# pacman -S git

Használja az AUR webhelyén látható „Git Clone URL-t” az adott csomaghoz:

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

Lépjen be a könyvtárba, és nézze meg a tartalmát. (Minden, ami itt szerepel, kivéve . .. .gita következőt PKGBUILD/ETC):

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

Ha megvizsgálja a PKGBUILD, remélhetőleg látni fogja, hogy a hivatalos upstream forráskódot használja, és tipikus lépéseket hajt végre a csomag felépítéséhez, tehát megbízhatónak tűnik. A .SRCINFOcsak a weboldalon feltüntetett információkat tartalmazza a csomagról, szóval nem aggasztó. Ha vannak itt más fájlok, azokat nem (közvetlenül) az upstream biztosítja, ezért PKGBUILDmeg kell vizsgálni a fájlokat és azok felhasználási módját , hogy megbizonyosodjunk arról, hogy semmi gyanúsat nem tartalmaznak.

Hivatalos adattárból

Bár sokkal ritkábban van rá szükség, már a hivatalos tárolókban is készíthet csomagot, új javítást, újabb verziót stb.

Szerezze be PKGBUILD/ETCa magból és az extra tárolókból:

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

A közösségi adattárból:

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

Frissítés PKGBUILD/ETC

Ha frissítést PKGBUILD/ETCadnak ki, visszatérhet ebbe a könyvtárba git clone, és frissítheti őket:

$ git pull

Ezután fordítsa újra és frissítse a csomagot az alábbi, választott módszerrel.

Összeállítás

A csomagok összeállításának számos módja van. Végső soron mindent használ makepkg. Két hivatalosan támogatott mód létezik:

• A közvetlen használathoz makepkglásd: https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• A közvetett használathoz makepkgtisztaban chrootlásd: https://www.vultr.com/docs/using-devtools-on-arch-linux .

Sok AUR segítő programok (mint a makepkgwrapper), hogy hivatalosan nem támogatott Arch, például aurutils, yayés a nemrég megszűnt aurman, és yaourt. Még akkor is, ha ezen egyéb segédprogramok valamelyikét használja, erősen ajánlott, hogy ismerkedjen meg a hivatalosan támogatott módszerekkel, hogy hatékonyabb legyen, ha valami elromlik.

A dokumentum többi része a YOUR BUILDERválasztott módszert jelenti.

Helyi adattár

Beállíthat egy helyi adattárat, hogy az legyen az összes összeállított csomag központi helye.

Helyezze el a helyi adattárat a kívánt helyre:

# mkdir /archLocalRepo

Futtassa YOUR BUILDERaz automatikus telepítési opciók nélkül, és másolja a csomagot a helyi tárolóba.

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

Adja hozzá az új csomagot a lerakatindexhez:

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

Egy csomag eltávolítása a lerakat indexéből és magából a csomagfájlból:

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

Ha le kell cserélnie egy meglévő csomagfájlt, külön el kell távolítania a lecserélt fájlt, majd hozzáadnia kell az újat. Nem másolhatja egyszerűen az új fájlt a régire.

Szerkessze pacmanbe a helyi tárhely használatát /etc/pacman.conf, és adja hozzá a következőket a végéhez:

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

Fel kell pacmanfrissítenie tudását a tárhelyről (beleértve a helyit is), adatbázisokról; a hozzá adott csomagok megtekintéséhez:

# pacman -Sy

Ezután telepítheti a csomagot, nem másként, mintha egy hivatalos tárolóban lenne:

# pacman -S <PKGNAME>

Ne feledje, ha a csomag csupán egy másik csomag függősége, amelyet telepíteni fog, akkor nem kell közvetlenül telepítenie. A másik csomag telepítésekor pacmanautomatikusan megkeresi és telepíti a függőségi csomagokat a helyi tárolóban.

Fordíts gyorsabban

Alapértelmezés szerint YOUR BUILDERegyetlen szál használatával fordít. Több CPU-s rendszereken lehetőség szerint engedélyezheti több szál használatát. A build rendszer párhuzamosan fordítja le a forráskód egyes részeit, amikor csak lehetséges. Néha a kód részei megkövetelik, hogy más részek, amelyekkel kölcsönhatásba lépnek, már le legyenek fordítva, így nem mindig fog annyi szálat használni, amennyi megengedett. Szerkesztés /etc/makepkg.conf.

Ha annyi szálat szeretne használni, ahány virtuális magja van, adja hozzá a következőket:

MAKEFLAGS="-j$(nproc)"

Megjegyzés: Ez nprocminden alkalommal futtatja a parancsot , így mindig az aktuális számú magot fogja használni, ha frissíti a Vultr szervert

Ha engedélyezni szeretné több virtuális mag használatát, de nem mindegyiket, például csökkenti a rendszer teljes teljesítményére gyakorolt ​​hatást, adjon hozzá egy adott számot. Például, ha 24 magja van, engedélyezheti 21 használatát:

MAKEFLAGS="-j21"

A virtuális magok számánál több szál megadása csökkenti a teljesítményt.

Meglehetősen ritka, de egyes csomagok összeállítási rendszereinek problémái vannak a párhuzamos fordítással, mivel nem határozzák meg megfelelően a függőséget a kód részei között. Általában ezeknek a csomagoknak a PKGBUILDfájljai kezelik ezt helyetted a meghívással make -j1, amely felülírja a beállított alapértelmezett értéket. Ha erre van szüksége, és hiányzik, jelentse az Arch csomag karbantartójának.

PGP aláírási hiba

A PKGBUILDforrástömb tartalmazhat .ascvagy .sigfájlokat. Gyakran szerepelnek a bash kapcsos kiterjesztésben, így könnyen kihagyhatók:

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

Ha az aláírásfájlok ezen formátumai közül bármelyik szerepel a forrástömbben, YOUR BUILDERautomatikusan megkísérli ellenőrizni a felfelé irányuló forrásarchívum aláírását. Az aláírás PGP-kulcsának a felhasználó kulcstartójában kell lennie; ellenkező esetben megszakad a következő hibával:

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

Fontos megérteni, hogy egy GPG-kulcs többféleképpen is megjeleníthető. Az ujjlenyomata 40 hexadecimális karakterből áll, és mindig ezt kell használni. A hosszú kulcs azonosítója az utolsó 16 számjegy, a rövid kulcs azonosítója az utolsó 8 számjegy. Bár a rövidebb kényelmes, lehetővé teszi a duplikációkat, amelyek semmissé teszik az aláírások ellenőrzése mögött meghúzódó érvelést. Ami még rosszabb, a támadókról köztudott, hogy hamis kulcsokat generálnak, amelyek megfelelnek a nagy horderejű fejlesztők kisebb hosszúságú kulcsainak.

Szerezze be és ellenőrizze a PGP-kulcs ujjlenyomatát

Ha még nem próbáltad felépíteni a csomagot, töltsd le a forrásokat, amelyek tartalmazzák az aláírási fájlt: (Ha megpróbáltad az összeállítást, már ott lesz)

$ makepkg --nobuild --noextract

A teljes ujjlenyomat beszerzéséhez:

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

Ideális esetben ezt az ujjlenyomatot az áramlás irányából kell ellenőriznie. A biztonság érdekében az upstreamnek meg kell adnia karbantartói kulcsait valahol a webhelyén vagy a forrásban. Pusztán a kulcs keresése egy kulcsszerveren nem vezet semmihez. A támadó könnyen beküldhet hamis kulcsot, mivel a kulcsszerverek nem ellenőrzik a hitelességet. A kulcsok aláírhatók más kulccsal is, így ha már rendelkezik olyan kulccsal, amelyben megbízik, meglehetősen biztonságosnak kell lennie az általuk aláírt kulcsokban.

Ez elég sok munka lehet, különösen akkor, ha az upstream nem teszi közzé az ujjlenyomatát, vagy nem helyezi el olyan helyre, ahol könnyen megtalálható. Az PKGBUILDakarat egy validpgpkeystömböt tartalmaz , amelyet az Arch karbantartója adott hozzá. Ha a csomag egy hivatalos adattár, ez azt jelenti, hogy egy Megbízható felhasználó helyezte el oda, és meglehetősen biztonságosnak kell lennie, ha a tömbben felsorolt ​​dolgokban megbízhat. Ha a csomag az AUR-ban van, ne feledje, hogy ez csak azt jelenti, hogy egy másik Arch felhasználó helyezte oda. Ha aggályos, hogy megbízik-e benne, mindig belenézhet a felhasználóba, hogy megtudja, mit csinált a múltban az Arch segítségével.

Adja hozzá a PGP-kulcsot a kulcstartójához

Ujjlenyomat hozzáadásához a kulcstartóhoz:

$ gpg --recv-keys <FINGERPRINT>

Most már futtathatja a YOUR BUILDER, és megbízik az ujjlenyomatban.

AUR fejlesztői csomagok

AUR csomagok nevek végződő -git, -svn, -bzrvagy -hga fejlődési változatok, amelyek használata upstream legújabb verziója rendszer elkövetni helyett upstream legújabb kiadása. Például a-gitcsomag az upstream legfrissebb véglegesítését használja a fő ágban (vagy az azzal egyenértékű ágban). Ez nagyszerűen használható felfelé irányuló hibajavítások és új szolgáltatások futtatásához, amelyeket még nem adtak ki, és amikor az upstream szolgáltatással dolgozik egy jelentett hibán, beleértve azt is, ha ellenőriznie kell, hogy ez nem egy olyan hiba, amelyet még nem kiadásban lévő véglegesítés javított ki. Ezeket a csomagokat potenciálisan instabilnak kell tekinteni. Ennek ellenére sajnos néha nincs alternatíva, mert egyes upstream karbantartók soha nem címkézik meg a kiadásokat, vagy túl hosszúra nyúlnak el a kiadások címkézése között, és mindenkitől elvárják, hogy a legutóbbi véglegesítését használja. A csomagtól függően előfordulhat, hogy Ön lesz az első, aki megpróbálja futtatni a véglegesítést. Az upstream fejlesztőktől függően előfordulhat, hogy a legutóbbi commit még le sem fordítja,

Fontos megérteni egy gyakori hibát. Ne jelöljön meg egy AUR fejlesztői csomagot elavultként pusztán azért, mert régi verziószámot mutat! A fejlesztői csomagfájlok PKGBUILDtartalmaznak egy további funkciót is pkgver(), amely a frissítések automatikus elemzésére szolgál az PKGVERupstream forráskódjából. A -gitcsomagok általános formátuma a <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Előfordulhat, hogy egy csomag az AUR-ban ként szerepel 5.0.0.r102.8d7b42ac21-1, mert ez az, amit PKGBUILDtartalmaz. De amikor létrehoz egy csomagot, YOUR BUILDERaz automatikusan frissül, PKGVERhogy tükrözze az újonnan letöltött forráskódot. Valójában, ha sok új verziót adtak ki, de semmi sem változott az építési folyamatban, akkor PKGBUILDegy régi verzió listázása valami sokkal újabb építését eredményezheti, mint pl.9.1.2.r53.2c9a41b723-1. Ezeknél a csomagoknál a webhelyen felsorolt ​​verzió egyszerűen a legújabb verzió, amikor az AUR karbantartónak utoljára frissítenie kellett a PKGBUILD.

Az AUR karbantartóinak NEM szabad csak frissíteniük az PKGVERúj verziókat. Ezt csak akkor kell megtenniük, ha az újabb upstream commitokhoz valójában valami mást PKGBUILDkell megváltoztatni.

Csak akkor jelölje meg az elavult fejlesztési AUR-csomagot, ha tudja, hogy valami nincs rendben. Ez azt jelenti, hogy valóban megpróbáltad használni, de nem sikerül a megfelelően formázott új formátum fordítása vagy elemzése PKGVER. Néha előfordulnak olyan dolgok, amelyek arra kényszerítik az AUR-karbantartót, hogy frissítse a fájlt PKGBUILD, például a upstream függőségek megváltoznak, az configureopciók módosulnak, az új GCC-verziók olyan hibákat vesznek fel a forráskódban, amelyeket a korábbiak nem, a upstream adattárak helye megváltozik, vagy a korábbi fejlesztők megváltoztatják a tipikus verziójuk helyét. a forráskódon belül van megtörve aPKGVERelemző funkció. Értse meg, hogy még akkor is, ha a fordítás vagy a működés meghiúsul, ez vagy azt jelentheti, hogy az AUR-karbantartónak módosítania kell a felépítési folyamatát, vagy lehet, hogy egy olyan upstream probléma a forráskóddal, amelyért az AUR-karbantartó nem vállal felelősséget.

Elavult csomagok

Feltétlenül olvassa el a fenti "AUR Fejlesztési Csomagok" részt, mielőtt egy csomagot elavultként jelentene!

Ha az upstream egy újabb verziót adott ki egy nem fejlesztői csomaghoz, mint a PKGBUILD, kattintson a "Csomag jelölése elavultként" elemre, és írjon be egy üzenetet a karbantartónak. Használja a https://packages.archlinux.org címet a hivatalos tárolócsomagokhoz, és a https://aur.archlinux.org oldalt az AUR csomagokhoz. Hasznos üzenet lehet az új verziószám, és esetleg egy hivatkozás a kiadási bejelentésre vagy a forráskódra. A megjelölés funkció automatikusan elküldi az üzenetet a karbantartónak.

Ha egy AUR-csomagon nem érkezik válasz 2 hét elteltével, kattintson a "Kérés elküldése" gombra "Orphan" típussal, ha meg szeretné kérni egy Megbízható Felhasználót, hogy távolítsa el a jelenlegi karbantartót, és tegye árva csomagot, ha a fenntartó nem válaszol az árva megkeresésre. Általában az emberek csak akkor nyújtanak be árva kérelmeket, ha képesek és hajlandók átvenni a csomagot, és lehetőleg csak akkor, ha már rendelkezik működő árammal PKGBUILD.

Eközben gyakran maga is frissíthet egy elavult csomagot. Gyakran csak úgy kell módosítania, PKGBUILDhogy frissíti PKGVERaz új verziószámot, és az integritási összegek frissülnek. A updpkgsumscsomagban létezik egy program pacman-contrib, amely automatikusan kiszámítja az összegeket, és frissíti azokat PKGBUILDaz Ön számára. Érdemes megnézni az upstream kiadási megjegyzéseit, hátha megemlítik, hogy valamit változtatni kell az új verzió telepítése során. Néha az upstream változtatások további változtatásokat vagy alapjavítást igényelnek PKGBUILD/ETC. Gyakran a sourcetömb beágyazódik PKGVER, így gyakran nem is kell frissíteni.