A je tu další ohlédnutí se za DevConfem. Jaká je budoucnost RPM ve fedoře? Will Woods a Stephen Gallager se zabývali tím, jak se používají RPM a co jim vadí na skiptletech.
První otázkou je co jsou vlastně skriptlety a jak zapadají do fungování RPM. Osobně bych použití balíčků rozdělil do dvou fází. V první fázi se správce balíčku snaží vzít zdrojáky programu a udělat z nich binárky (ve spec jsou to %prep %build %check %install %clean). Ve druhé fázi balíček vezme uživatel a nainstaluje ho nebo aktualizuje na novejší verzi. Nahrají se soubory (%files) a spustí se právě ty skriptlety (%pre, %post, %posttrans, atd. ).
Skriptlet je zřejmě kombinace slov shell a kripl.
Co jsou to ty skriptlety? Je to všechno možné jenom ne soubory. Nejčastěji jsou to bashové skripty, ale můžou být napsané třeba v LUA (u %pretrans se to dokonce doporučuje) nebo jiném jazyce. Většinou jsou podle Fedora Packaging Guideline. Problém je ale v tom zbytku.
V RPM balíčcích se objevují různé jazyky od C, přes Javu, Perl, LUA nebo Rust. Pro balíčkování různých typů komponent se používají různé triky. Existují doporučení (makra) jak to dělat správně pro různé typy software. Pro Systemd, kontejnery, aplikace s uživatelským rozhraním, atd. Když se do toho zamíchají podmínky pro různé verze RHELu nebo Fedory, tak je obtížné se vyznat i v tom pěkném kódu podle guideline. O tom “škaredém” kódu se potom dá jen velmi těžko říct jak se to bude chovat.
RPM se do počítače instalují pod rootem, takže ním beží i všechny skriptlety. Instalace cizího balíčku je tedy bezpečná asi jako copy paste cizího kódu z webu
curl http://blog.mlich.cz/install.sh | bash
Je to pomalé. Zkuste si třeba nainstalovat všechny balíčky texlive a pak s nimi aktualizovat Fedoru.
Na druhou stranu jsou skriptlety nedotažené. Při instalaci se nezpracovávají chybové kódy. Pokud jste někde v souvislosti s RPM balíčky zahlédli slovo “transakce”, tak se nenechte zmýlit. Pokud selže instalace RPM v nějakém skriptelu, tak to vypíše chybu a pokračuje to dál. Nejde udělat plnohodnotný ROLLBACK (dnf history redo|rollback|undo). Když skriptlet něco smaže nebo přepíše, tak to prostě nejde vrátit zpět. Řešením by byl nějaký overlayfs nebo snapshot. Nejde ani dobře zjistit jestli se něco zaseklo v nekonečné smyčce nebo jestli je to v půlce nebo jak dlouho zbývá do konce..
To celé musí dobře fungovat nejen pro instalaci, ale i odebrání a aktualizaci balíčku. Podle Willa a Stephana existuje přes 80 různých spouštěčů (trigger) skriptletů. Nevím úplně jak se k tomu číslu dopočítali. V každém případě máme %pretrans %pre %post %preun %postun a %posttrans, které jsou navíc parametrizované, kde $1 může být 0, 1 nebo 2 podle toho jestli je to instalace, aktualizace nebo odinstalace. Do toho se samozřejmě míchají skriptlety od ostatních balíčků.
Pak pánové udělali demo, ve kterém vyrobili qcow image, jenom s použitím sekce %files bez spouštění skriptletů. Byl to takový hack, protože doplnili nějaké drobnosti ručně. Vyrobení qcow trvalo pár vteřin a překvapivě to celé fungovalo.
Skriptlety dělají různé věci a ty se dají řešit pomocí pomocí souborů. V některých případech se dají upravit existující makra:
- vytváření uživatelů a skupin – systemd sysusers (už to mělo být od f22)
- přidání, povolení, zakázání služby – systemd makro
- vytváření prázdných souborů – tmpfiles.d makro
- generování dat specifických pro daný systém – systemd služba pro inicializaci
- nastavení OS (SELinux, firewall) – tohle zakážeme v guideline (-;
- aktualizace katalogů a cache – vytvoří se nějaký soubor, který vyvolá aktualizaci katalogu.
Není třeba volat ldconfig při instalaci každého balíčku. Ve skutečnosti prý není potřeba ldconfig volat nikdy, protože vše se instaluje do standardních cest.
Problém může nastat například u /etc/alternatives, které se hodně používají v debianu a fedora je víceméně toleruje. Podle mých zkušeností to ve fedoře funguje spíš špatně.
Celkově by se Will, Stephen i já chtěli zbavit co nejvíc skriptletů. Uvidíme jestli a jak se jim to podaří prosadit ve Fedoře.
