Instalace softwaru v Linuxu - 2 (Autopackage)

23. 4. 2007 | Michal Vyskočil | Systém | 6840×

Autopackage je první z řady nezávislých balíčkovacích systémů, které si v tomto seriálu představíme. Jeho cílem je umožnit instalaci předkompilovaných programů ze stejného balíčku na všech distribucích.

Obsah

• Balíčky
• Kam instalovat?
• GUI
• Podpůrné nástroje pro vývojáře
• Instalace a používání
• Závěr

Balíčky

Autopackage poskytuje definovaný způsob instalace a odinstalace softwaru. Umožňuje lokální instalaci do domovského adresáře, přičemž nezaručuje, že to bude možné pro jakýkoliv software. Součástí jsou podpůrné nástroje pro vytváření, instalaci a mazání balíčků v podobě knihovny shellových skriptů. Stejně tak i autopackage balíček je v podstatě shellový skript, který je generován výše zmíněnými nástroji. Díky tomu může být kontrola nejrůznějších závislostí komplikovaná, ovšem standardní knihovna poskytuje nástroje, které postačují pro většinu případů. Vzhledem k těmto problémům jsou však závislosti omezeny na název souboru nebo knihovny.

Tak trochu se soubory .autopackage podobají balíčkům ve Slackware, protože nedefinují žádný vlastní repozitář ani složitý systém závislostí. Všechno potřebné je obsaženo ve vlastním balíčku a pokud náhodou závisí na jiném, obsahuje URL, z něhož si jej stáhne a automaticky nainstaluje. Reverzní závislosti řešeny nejsou, takže pokud někdo ten druhý odinstaluje, první balíček přestane správně pracovat.

Kam instalovat?

Zatím je k dispozici několik desítek balíčků. Komunita kolem autopackage má ovšem mnoho sporů s distributory. Největší odpor vyvolává nedodržování FHS ze strany týmu autopackage, jejichž balíčky se instalují přímo do /usr a mohou tak ovlivňovat stávající systém správy balíčků. Argumentem vývojářů autopackage je, že mnoho distribucí /usr/local nepodporuje správně (především nastavené cesty).

Buď jak buď, tato situace nepomáhá nikomu. Nejrozumnějším řešením by bylo tlačit na zmíněné distributory, aby podporu pro /usr/local přidali do svého výchozího nastavení, nebo prostě připravit skripty, které nastavení upraví. Současný stav, při kterém může instalace balíku pomocí autopackage narušit stávající systém, je špatný. V plánu je podpora pro automatický update systému, který umožní povyšovat verze aplikací stejně komfortně jako u stávajících balíčkovacích systémů.

GUI

Vývojáři poskytují grafické uživatelské rozhraní (GTK+ i Qt), takže z hlediska uživatele se jedná (respektive by se mělo jednat, viz dále zkušenosti) o jednoduchou záležitost. Ovšem uvnitř systému existuje několik nedostatků. Ten první s adresářem /usr byl již zmíněn. Dalším problémem je, že se jedná o kombinaci skriptu a binárky, která se přímo spustí. Přes možnosti podepisování balíčků se jedná o potenciálně velmi rizikovou záležitost a mnoho tvůrců (zejména bezpečnostních aplikací) nebude chtít touto formou svůj software poskytovat, resp. mnoho administrátorů nebude chtít podobným způsobem instalovat. Posledním problémem je řešení závislostí pomocí shellu a s tím spojená malá škálovatelnost takového řešení. Navíc není možné dělat závislosti na virtuální balíčky (což souvisí s neexistující konvencí pro jejich pojmenování).

Podpůrné nástroje pro vývojáře

Binárky produkované pomocí autopackage jsou přemístitelné (relocatable), k čemuž si vývojáři napsali vlastní aplikaci zvanou BinReloc. Problémem je, že klasické binárky nebývají přenositelné, ale při kompilaci se jim nastaví cesty. Win32 API obsahuje funkci GetModuleFilename(), jejíž ekvivalent v unixech neexistuje. BinReloc je malý kód v jazyce C, který existuje ve dvou verzích: v čistém C a variantě, která má API ekvivalentní s glib. Kód se staticky slinkuje s programem nebo knihovnou, je od té chvíle možné v kódu volat funkce jako br_find_exe() a podobně. Makro ENABLE_BINRELOC zapíná jeho podporu. Od dubna 2004 je v knihovnách KDE třída KStandardDirs, která pro apliKace poskytuje stejnou funkčnost.

Projekt nabízí další podpůrné nástroje. Protože autoři tvrdí, že je API funkcí dlopen()/dlsym() přiliš složité, nabízejí relaytool, který při překladu vygeneruje pahýl knihovny nutný pro "oblbnutí linkeru". Nebo wrapper nad překladačem gcc apgcc, který mimo jiné řeší i problém rozdílného C++ ABI v gcc verze 3.2 a 3.4. Další nástroj je scandeps, který rekurzivně prohledává adresář a pro všechny EFL binárky hledá závislosti.

Instalace a používání

Nejprve je nutné do systému nainstalovat autopackage. Je to docela potíž, protože na webu projektu nějaký pořádný návod chybí. Začne se stažením archívu s poslední verzí, jeho rozbalením a spuštěním skriptu install. O tento krok se snažily samotné autopackage balíčky, ale ani jednou proces nedotáhly do konce. Pozor, je nutné být uživatel root; skript se sice tváří, že instalace proběhla pod běžným uživatelem úspěšně, ale nevěřte mu! Navíc nabídne i možnost instalace Gtk+ rozhraní. Ovšem zase ukazuje, že se mu nedá věřit, protože hláška

Unable to download, skipping installation of graphical interface...

po úspěšném stažení, rozbalení a nakopírování příslušných souborů nevypadá příliš dobře. To, co je důležitější, je fakt, že nás seznámí s jistým příkazem (package remove autopackage-gtk), což je příkaz pro odinstalaci. Příkaz package je tedy obdoba aptu pro tento systém.

V sekci HOWTO INSTALL je podrobný návod, jak balíček nainstalovat. Aby byla situace spravedlivá, jal jsem se instalovat Qt frontend pro autopackage (abych nebyl osočen z upřednostňování jednoho toolkitu).

Prohlížeč po kliknutí nabídne jeho uložení:

ovšem v prostředí KDE není definována aplikace pro soubory .package (autopackage-launcher-gtk).

Zobrazí se tedy okno s dotazem, zda chceme instalovat, a po chvilce i nezbytný dialog pro zadání hesla roota.

Nakonec se objeví okno s nápisem Succesful. Ovšem i zde mě systém vypekl. Skutečně netuším, z jakého důvodu software vypisuje přesně obrácené hlášky, než by odpovídaly situaci, protože se Qt frontend vůbec nenainstaloval.

Nezbytná byla konzolová instalace pomocí příkazů:

wget http://ftp.sunsite.dk/projects/autopackage/1.2/autopackage-qt-1.2.package
package install autopackage-qt-1.2.package

Potěšující může být automatická instalace do menu desktopového prostředí:

A zde jsou grafické manažery v Gtk+:

a v Qt verzi:

Dalším pánem na holení byl program Inkscape, ovšem situace se opakovala. Navíc se instalací Qt frontendu nejen zrušila asociace, ale Qt alternativa k autopackage-launcher-gtk prostě není. Vše proto vyřešila ruční instalace v konzoli. Ovšem konzolová verze pokaždé zobrazí grafické okno s dotazem na heslo roota, přes které se mi nepodařilo nikdy projít. Nakonec mě zachránil příkaz su -c.

Nakonec se podařilo Inkscape v pořádku nainstalovat i spustit. Ovšem grafické nástroje opět nezklamaly - když už (ne)fungují podivně, tak alespoň důsledně. Qt verze se zasekla na nápisu Please wait while the application you selected is removed.... Teprve po zavření tohoto okna se objevil dialog pro zadání hesla a nakonec se spustil i odinstalační proces. Gtk+ verze mi sice ten dialog zobrazila správně, ale po zadání hesla se nestalo nic. Proto jsem se vrátil k osvědčené konzoli a vše odstranil ručně pomocí

autopackage remove autopackage-qt autopackage-gtk

Horší to bylo s vyčištěním systému od samotného autopackage, protože autoři s tím evidentně nepočítají. Nakonec tedy pomohlo ruční smazání příkazem

rm -rf /etc/autopackage /usr/share/autopackage \
 /usr/libexec/autopackage /usr/bin/package

Závěr

Z výsledků Autopackage jsem docela rozpačitý. Na jednu stranu fungující příkaz package, který poskytuje známé rozhraní pro správu balíčků, a pár technických fines, které tvůrci systému implementovali. Na straně druhé zmatená dokumentace, podivné grafické nadstavby, zásahy do vlastního systému, ... Systém rozhodně potřebuje dozrát a získat větší stabilitu, ovšem otázkou zůstává, jako moc se administrátoři (a distributoři) dokáží smířit s tím, že je .autopackage skript běžící s právy roota a navíc zasahuje do adresářové struktury, která by měla být hájemstvím balíčkovacího systému.

       

Komentáře

[thingie]

Tento článek jsou hrozné a děsivé lži!

(no, a teď si ho jdu přečíst :o))

[lev]

Myslím, že Michal mohl napsat distro na kterém to zkoušel i když je to určeno všem distribucím a taky to zkusit alespoň na dalších dvou.

[Michal Vyskočil]

Distribuce byla Mandriva 2007. Je pravda, že jsem to mohl, podobně jako tehdy smart, otestovat na více distrech ...

[NbS]

Myslim, ze La Ora je theme pouzivane pouze Mandrivou :)) jak je ze screenu jasne

[Petr Tomášek]

Je to prasárna, k čemu když jsou máme balíčkovací systémy pro jednolivé distribuce? To už si to člověk může installovat ze zdrojáků a vyjde to nastejno...

(Pravda, autopackage nemůžu přijít na jméno od té doby, co kvůli němu přestal vydávat Abiword RPM-ka pro FEDORu - pod záminkou: „máš to v autopackage“).

[Josef Kufner]

Jo, taky si myslím. Jestli má smysl něco v tomhle směru dělat, tak leda nějaké standardizované API nad skutečným balíčkovacím systémem (jak už mnozí psali a říkali).

Dva balíčkovací systémy jsou snad i horší než žádný.

[Jirka Wolny]

No, mně by se naopak existence dvou balíčkovacích systémů líbila.

První systém by obsahoval balíčky silně optimalizované pro danou distribuci (všechny programy by byly překompilovány oproti tým samým knihovnám, všechny knihovny by byly sdílené a linkované dynamicky, ...). Tento systém by byl preferovaný pro open-souce aplikace, mělo by jím být nainstalováno 99% všech balíčků.

Druhý balíčkovací systém by se naopak snažil maximální univerzalitu (nezávislost na distribuci). Ke všem aplikacím by byly knihovny přilinkovány staticky, balíček by měl mít minimum závislostí. Tímto druhým balíčkovacím systémem by byly šířeny převážně komerční a closed-source aplikace. Normální uživatel by měl nainstalovány asi tak dva, tři programy tímto způsobem.

I když si nejsem jistý, jestli autopackage chce být tím druhým univerzálním balíčkovacím systémem.

[Josef Kufner]

Ale tohle bude vždy dělat problémy, protože ten hlavní balíčkovací systém v klidu dovolí odinstalovat něco na čem závisí něco z toho univerzálního. Prostě to nemůže nikdy pořádně fungovat.

[Jiří (BoodOk) Kadeřávek]

To druhé dělá klik, obdoba DMG v Mac OS X (tedy zapackovaný image disku s potřebnými závislostmi) a nemusí přitom zasahovat do /usr.

[Dalibor Smolík]

Se zájmem jsem si článek přečetl, ale myslím si, že mi aptitude a dpkg u Debianu naprosto stačí

[spectrum]

A mně zas stačilo přečíst si tento komentář. Jo, není kam spěchat ...

[Michal Vyskočil]

Takže já příště požádám pana Smolíka o napsání komentáře a ten se bude číst místo článku

[Dalibor Smolík]

Tak to bych vám moc neradil. Slabší povahy by mohly mít noční běsy.

[BrainLess]

Osobne si myslim ze tato aktivita byt s jiste bohulibim zamyslem je kontraproduktivni. Na jednu stranu je krasne ze Linux dava lidem svobodu ale na druhou stranu se imho zabiji sam tim ze tu vladne anarchie. Za krasny priklad anarchie povazuji prave vytvoreni (kolikateho uz ) balickovaciho systemu autopackage. Stovky distribuci, desitky balickovacich systemu, v kazde distribuci se vsechno konfiguruje jinak. Aby se v tom prase vyznalo.

[BrainLess]

Krasna ukazka tristeni sil. A toho jak vytvorit projekt jen proto abych mohl neco delat a zviditelnit se. Dekuji nechci.

[dusan]

Že to vobec niekoho napadá robyť. Nestaci rpm(nadstavby smart urpmi) a debian package. Nechapem načo to všetko.

Keď už tak by sa mali také extra programy inštalovať do /home/uživateľ/programy/program alebo do /usr/local/program s vlastnymi binarnimi libkami. (napríklad ako Q4demo)

Ale aj tak v konečnom dôsledku by sa mali potom dať do depozitárov tej ktorej distribucie keď bude o extra program záujem.

[svaca]

To je o cem jsme se tu bavili milionkrat ....

1. bud mam sve distro, kde je vse a funguje to jak ma
2. nebo nemam sve distro a pouzivam Slackware a pod a RESIM vse SAM

Ostatni je paskvil ...