Vytváření balíčků na Arch Linuxu (včetně AUR)

Na Arch Linuxu jsou oficiálními repozitáři: core, extra a community. Tyto balíčky jsou již zkompilovány a instalují se prostřednictvím pacman. Z velké části mohou běžní uživatelé ignorovat, že tato 3 oficiální úložiště jsou oddělená. Core obsahuje nejkritičtější balíčky, jako je jádro, bootovací proces, síťování, správa balíčků, openssh a tak dále. Má také přísnější požadavky na důkladnější testování před vydáním nových verzí. Extra obsahuje další oblíbené balíčky, které nejsou tak důležité, jako je X server, správci oken nebo webové prohlížeče. Komunita obsahuje méně oblíbené balíčky. Pouze důvěryhodní uživatelé (asi 60 aktivních uživatelů, o kterých hlasovali ostatní důvěryhodní uživatelé) mají přístup k provádění změn v oficiálních úložištích.

V roce 2019 je v oficiálních repozitářích na https://www.archlinux.org/packages asi 11 000 balíčků . V Linuxu je však k dispozici mnoho dalších programů. Existuje tedy AUR (Arch Linux User Repository), takže každý uživatel Archu může přidat nový program a stát se jeho správcem nebo přijmout „osiřelý“ balíček bez aktuálního správce. V AUR na https://aur.archlinux.org/ je asi 55 000 balíčků .

V porovnání s AUR existují 3 zásadní rozdíly:

1. Opět platí, že tyto obaly může vyrobit každý uživatel, dokonce i zcela nový.
2. AUR obsahuje pouze PKGBUILDskript Shell pro automatické vytvoření balíčku, nikoli kompilované binární soubory. (Někdy také obsahuje malé textové záplaty nebo skripty shellu install/upgrade/uninstall). To odvedlo ohromnou práci a umožnilo každému uživateli přispívat a zároveň zmírnilo možnost, že by někdo mohl distribuovat škodlivý kód. Komunita Arch je stále docela nápomocná ohledně problémů s balíčky AUR, ale je třeba poznamenat, že jejich použití je na vaše vlastní riziko. Protože vše, co poskytuje, je PKGBUILD, je v konečném důsledku vaší odpovědností zkontrolovat a, které PKGBUILDbudete používat. (Je pravda, že mnoho uživatelů to nedělá a spoléhá se na to, že ostatní budou sledovat.)
3. Protože pacmanpřímo neinteraguje s AUR, je vaší odpovědností aktualizovat balíčky AUR. Když pravidelně upgradujete celý systém prostřednictvím pacman, nebude automaticky stahovat aktualizace PKGBUILDsouborů AUR , kompilovat je a instalovat je za vás.

Ačkoli se tento článek zaměřuje na vytváření balíčků z AUR, stejné techniky lze použít k vytvoření balíčků z oficiálních repozitářů sami.

PKGBUILD

Ve srovnání se .specsouborem, který používá mnoho jiných distribucí, PKGBUILDje a krátký a jednoduchý shell skript. Ačkoli jsou některé balíčky složitější, mohou být jednoduše podobné následujícím:

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
}

Tento dokument odkazuje na:

• PKGNAME: Název balíčku
• PKGVER: Verze balíčku (téměř vždy se shoduje s číslem verze proti proudu)
• PKGREL: Arch "verze" PKGBUILDpro konkrétní PKGVER(normálně 1, ale navýšeno, pokud je třeba provést změny PKGBUILDmezi upstream vydáními)
• ARCH: Architektury, na kterých může být balíček postaven (poněkud zastaralé, protože oficiální repozitáře Arch Linuxu podporují pouze "x86_64" (64bitové CPU), ale balíčky AUR mohou stále podporovat "i686" (32bitové CPU) nebo "jakékoli" označovat architekturu je irelevantní)
• PKGBUILD/ETC: Jakékoli soubory skutečně v úložišti AUR; the PKGBUILDa jakékoli další malé textové záplaty nebo skripty shellu pro instalaci/upgrade/odinstalaci. Nezahrnuje upstream soubory v sourcepoli.

Ačkoli se AUR ukázal jako extrémně důvěryhodný, je dobré se na něj podívat, PKGBUILD/ETCabyste se ujistili, že získává zdroj z místa, kterému jste ochotni důvěřovat; (například oficiální upstream umístění, které může pocházet z githubu – ale ne pouze z repozitáře github nějaké náhodné osoby, která nesouvisí s balíčkem upstream); a že PKGBUILD/ETCneobsahuje žádný podezřelý kód.

Získávání PKGBUILD/ETC

Z AUR

Pokud oficiální úložiště neobsahují balíček, který chcete nainstalovat, vyhledejte jej na https://aur.archlinux.org/ . Doufejme, že zjistíte, že to, co hledáte, existuje, je aktuální a udržované.

Nejlepší způsob, jak získat PKGBUILD/ETCz AUR, je naklonovat jej přes git.

Nainstalujte git, pokud již není:

# pacman -S git

Použijte "Git Clone URL" uvedenou na webu AUR pro daný balíček:

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

Vstupte do adresáře a podívejte se na jeho obsah. (Vše, co zde uvedeny, s výjimkou . .. .gitje PKGBUILD/ETC):

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

Pokud prozkoumáte PKGBUILD, doufejme, že používá oficiální zdrojový kód upstream a provádí typické kroky k sestavení balíčku, takže vypadá důvěryhodně. .SRCINFOObsahuje pouze informace uvedené na internetových stránkách o balíčku, takže není znepokojující. Pokud jsou zde nějaké další soubory, nejsou (přímo) poskytovány upstreamem, takže PKGBUILDby měly být prozkoumány soubory a způsob jejich použití v souboru , abyste se ujistili, že neobsahují nic podezřelého.

Z oficiálních repozitářů

Ačkoli to vyžaduje mnohem méně často, můžete sestavit balíček již v oficiálních repozitářích, zahrnout do něj nový patch, sestavit novější verzi atd.

Získejte PKGBUILD/ETCz jádra a dalších úložišť:

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

Z komunitního úložiště:

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

Upgrade PKGBUILD/ETC

Pokud PKGBUILD/ETCje vydán upgradovaný , můžete se vrátit do tohoto adresáře vytvořeného pomocí git clonea aktualizovat je:

$ git pull

Poté balíček znovu zkompilujte a upgradujte pomocí metody dle vašeho výběru níže.

Kompilace

Existuje mnoho způsobů, jak kompilovat balíčky. Nakonec vše používá makepkg. Existují 2 oficiálně podporované způsoby:

• Pro přímé použití makepkgviz https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Chcete-li nepřímo použít makepkgv čistém prostředí chroot, přejděte na https://www.vultr.com/docs/using-devtools-on-arch-linux .

Existuje mnoho pomocných programů AUR (jako makepkgwrapper), které nejsou oficiálně podporovány Archem, jako jsou aurutils, yay, a nedávno ukončené aurmana yaourt. I když používáte některý z těchto dalších pomocných programů, důrazně se doporučuje seznámit se s oficiálně podporovanými způsoby, jak být efektivnější, když se něco pokazí.

Zbytek tohoto dokumentu bude YOUR BUILDERznamenat jakoukoli metodu, kterou zvolíte.

Místní úložiště

Můžete nastavit místní úložiště jako centrální umístění pro všechny balíčky, které vytvoříte.

Umístěte místní úložiště kamkoli budete chtít:

# mkdir /archLocalRepo

Spusťte YOUR BUILDERbez jakýchkoli možností automatické instalace a zkopírujte balíček do místního úložiště.

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

Přidejte nový balíček do indexu úložiště:

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

Chcete-li odebrat balíček z indexu úložiště a samotného souboru balíčku:

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

Pokud potřebujete nahradit existující soubor balíčku, musíte samostatně odebrat nahrazovaný soubor a poté přidat nový. Nemůžete jednoduše zkopírovat nový soubor přes starý.

Nakonfigurujte pacmanpoužití místního úložiště úpravou /etc/pacman.confa na konec přidejte následující:

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

Musíte pacmanobnovit jeho znalosti o úložišti (včetně vašeho místního), databázích; pro zobrazení balíčků, které jste do něj přidali:

# pacman -Sy

Poté můžete balíček nainstalovat, ne jinak, než kdyby byl v oficiálním úložišti:

# pacman -S <PKGNAME>

Všimněte si, že pokud je balíček pouze závislostí jiného balíčku, který se chystáte instalovat, nemusíte jej instalovat přímo. Když nainstalujete tento další balíček, pacmanautomaticky vyhledá a nainstaluje balíčky závislostí ve vašem místním úložišti.

Kompilace rychleji

Ve výchozím nastavení se YOUR BUILDERkompiluje pomocí jednoho vlákna. Na systémech s více CPU můžete povolit použití více vláken, kde je to možné. Sestavovací systém bude kompilovat části zdrojového kódu paralelně, když to bude možné. Někdy části kódu vyžadují, aby další části, se kterými interaguje, byly již zkompilovány, takže ne vždy uvidíte tolik vláken, kolik je povoleno. Editovat /etc/makepkg.conf.

Chcete-li povolit použití tolika vláken, kolik máte virtuálních jader, přidejte následující:

MAKEFLAGS="-j$(nproc)"

Poznámka: Toto spustí příkaz nprocpokaždé, takže vždy použije aktuální počet jader v případě, že upgradujete server Vultr

Chcete-li povolit použití více virtuálních jader, ale ne všech z nich, jako je snížení dopadu na celkový výkon systému, přidejte konkrétní číslo. Pokud máte například 24 jader, můžete povolit použití 21:

MAKEFLAGS="-j21"

Pokud zadáte více vláken, než kolik máte virtuálních jader, snížíte výkon.

Je to poměrně vzácné, ale systémy sestavení některých balíčků mají problémy s paralelní kompilací, protože nejsou správně definovány závislosti mezi částmi kódu. PKGBUILDSoubory těchto balíčků to obvykle zpracují za vás vyvoláním make -j1, které přepíše výchozí nastavení, které jste nastavili. Pokud to potřebuje a chybí to, nahlaste to správci balíčku Arch.

Chyba podpisu PGP

PKGBUILDZdroj pole může obsahovat .ascnebo .sigsoubory. Často jsou zahrnuty pomocí rozšíření závorky bash, takže je lze snadno přehlédnout:

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

Pokud je některý z těchto formátů souborů podpisů zahrnut ve zdrojovém poli, YOUR BUILDERautomaticky se pokusí ověřit podpis upstream zdrojového archivu. Klíč PGP podpisu musí být ve svazku klíčů uživatele; jinak se přeruší s chybou:

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

Je důležité pochopit, že klíč GPG lze zobrazit několika způsoby. Jeho otisk je 40 hexadecimálních znaků a je to, co byste měli vždy používat. Dlouhé ID klíče je posledních 16 číslic a krátké ID klíče je posledních 8 číslic. I když kratší je výhodný, umožňuje duplikáty, které ruší veškeré úvahy o ověřování podpisů. Ještě horší je, že útočníci jsou známí tím, že generují falešné klíče, které odpovídají menším klíčům pro vysoce profilované vývojáře.

Získejte a ověřte otisk klíče PGP

Pokud jste balíček ještě nezkoušeli sestavit, stáhněte si zdroje, které budou obsahovat soubor s podpisem: (Pokud jste se pokusili sestavit, již tam bude)

$ makepkg --nobuild --noextract

Chcete-li získat úplný otisk prstu:

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

V ideálním případě byste měli tento otisk ověřit z upstreamu. Pro zajištění bezpečnosti by měl upstream poskytnout klíče svých správců někde na svých webových stránkách nebo ve zdroji. Pouhé hledání klíče na serveru klíčů ve skutečnosti nic nedělá. Útočník může snadno odeslat falešný klíč, protože servery klíčů neověřují pravost. Klíče mohou být podepsány jinými klíči, takže pokud již máte klíč, kterému důvěřujete, měli byste být celkem v bezpečí, když důvěřujete všem klíčům, které podepsaly.

To může být docela dost práce, zvláště když upstream nezveřejňuje svůj otisk prstu nebo jej neumístí někam, kde jej lze snadno najít. PKGBUILDBude obsahovat validpgpkeyspole, které byly přidány do Arch správce. Pokud je balíček oficiálním úložištěm, znamená to, že jej tam umístil Důvěryhodný uživatel a měli byste být v naprostém bezpečí, že důvěřujete čemukoli uvedenému v poli. Pokud je balíček v AUR, pamatujte, že to znamená, že jej tam umístil jiný uživatel Archu. Pokud se obáváte, že tomu důvěřujete, můžete se vždy podívat do uživatele a zjistit, co v minulosti s Archem udělal.

Přidejte klíč PGP do svého svazku klíčů

Přidání otisku prstu na klíčenku:

$ gpg --recv-keys <FINGERPRINT>

Nyní můžete spustit aplikaci YOUR BUILDERa bude důvěřovat otisku prstu.

Vývojové balíčky AUR

Balíčky AUR se jmény končícími -git, -svn, -bzrnebo -hgjsou vývojové verze, které místo posledního vydání upstreamu používají nejnovější verzi systému kontroly verzí. Například a-gitbalíček by používal nejnovější odevzdání upstreamu v hlavní větvi (nebo jejich ekvivalentní větvi.) To je skvělé pro spouštění oprav chyb a nových funkcí, které ještě nebyly vydány, a při práci s upstreamem na chybě, kterou hlásíte, včetně musíte u nich ověřit, že to není chyba, která byla opravena potvrzením, které ještě není ve verzi. Tyto balíčky by měly být považovány za potenciálně nestabilní. To znamená, že bohužel někdy neexistuje žádná alternativa, protože někteří upstream správci vydání nikdy neoznačují nebo mezi jednotlivými vydáními tagování příliš dlouho neoznačují a očekávají, že každý použije svůj nejnovější odevzdání. V závislosti na balíčku můžete být první osobou, která se pokusí spustit revizi. V závislosti na upstream vývojářích se jejich nejnovější potvrzení nemusí ani zkompilovat,

Je důležité pochopit běžnou chybu. Neoznačujte vývojový balíček AUR jako zastaralý jednoduše proto, že zobrazuje staré číslo verze! PKGBUILDSoubory vývojových balíčků obsahují další funkci pkgver(), která se používá k automatické analýze aktualizace PKGVERze zdrojového kódu upstreamu. Běžný formát pro -gitbalíček je <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Balíček může být uveden v AUR jako 5.0.0.r102.8d7b42ac21-1, protože to je to, co PKGBUILDobsahuje. Když však vytvoříte balíček, YOUR BUILDERautomaticky se aktualizuje, PKGVERaby odrážel nově stažený zdrojový kód. Ve skutečnosti, pokud bylo vydáno mnoho nových verzí, ale v procesu sestavení se nic nezměnilo, takové PKGBUILDuvedení staré verze by mohlo vést k vytvoření něčeho mnohem novějšího, jako je9.1.2.r53.2c9a41b723-1. U těchto balíčků je verze uvedená na webu jednoduše nejnovější verzí v době, kdy musel správce AUR naposledy aktualizovat soubor PKGBUILD.

Správci AUR NESMÍ pouze aktualizovat, PKGVERaby odrážely nové verze. Měli by tak učinit pouze tehdy, když novější upstream commity ve skutečnosti vyžadují něco jiného PKGBUILDke změně.

Označte vývojový balíček AUR za zastaralý, pouze pokud víte, že je něco skutečně špatně. To znamená, že jste se ho skutečně pokusili použít a selhává při kompilaci nebo analýze správně naformátovaného nového souboru PKGVER. Někdy se stanou věci, které donutí správce AUR aktualizovat soubor PKGBUILD, jako je změna upstreamových závislostí, změna configuremožností, nové verze GCC vychytají chyby ve zdrojovém kódu, které předchozí ne, změní se umístění úložišť proti proudu nebo se upstream vývojáři změní tam, kde jejich typická verze je ve zdrojovém kódu porušujícíPKGVERparsovací funkce. Pochopte, že i když selže při kompilaci nebo práci, může to znamenat, že správce AUR musí provést změny v procesu sestavování, nebo to může být problém se zdrojovým kódem, za který správce AUR nenese žádnou odpovědnost.

Zastaralé balíčky

Než nahlásíte balíček jako zastaralý, přečtěte si část „Vývojové balíčky AUR“ výše!

Pokud upstream vydal novější verzi pro nevývojový balíček než v PKGBUILD, můžete kliknout na "Označit balíček za neaktuální" a napsat zprávu správci. Pro balíčky oficiálního úložiště použijte https://packages.archlinux.org a pro balíčky AUR https://aur.archlinux.org . Užitečnou zprávou by bylo číslo nové verze a možná odkaz na oznámení o vydání nebo zdrojový kód. Funkce označování automaticky odešle vaši zprávu správci e-mailem.

Pokud u balíčku AUR neobdržíte žádnou odpověď po 2 týdnech, můžete kliknout na „Odeslat požadavek“ s typem „Orphan“, pokud chcete požádat Důvěryhodného uživatele, aby odstranil aktuálního správce a aby balíček osiřel, pokud správce nereaguje na žádost o sirotek. Obecně platí, že lidé podávají osiřelé žádosti pouze tehdy, pokud jsou schopni a ochotni balíček převzít, a pokud možno pouze tehdy, pokud již mají funkční proud PKGBUILD.

Mezitím můžete často aktualizovat zastaralý balíček sami. Často stačí změnit a PKGBUILDaktualizací PKGVERna nové číslo verze a součty integrity se aktualizují. V updpkgsumsbalíčku existuje program pacman-contrib, který automaticky vypočítá součty a aktualizuje je PKGBUILDza vás. Vyplatí se zkontrolovat poznámky k vydání upstream, abyste zjistili, zda se v nich nezmiňuje, že je třeba během procesu instalace nové verze něco změnit. Někdy proti proudu změny vyžadují více změn nebo generální opravy PKGBUILD/ETC. Často sourcepole vloží PKGVERdo něj, takže často není ani potřeba aktualizovat.