Zápisky z Berlína - 2. část: Plány LSB

8.1.2007 10:29 | Přečteno: 1483× |

Hlavním tématem celé konference bylo určení cílů pro další verze standardu LSB (aktuální verze je 3.1, připravuje se verze 3.2 a větší změny se chystají pro verzi 4.0) a stanovení konkrétních úkolů s tím souvisejících. Plány jsou poměrně rozsáhlé a o leckterých pasážích se strhla poměrně značná diskuse. Následuje stručný přehled toho, co bylo odsouhlaseno.

(Poznámka inspirovaná reakcemi na předchozí díl: Všechny údaje čerpám ze svých poznámek a paměti; ani jedno není dokonalé. Pokud něco z toho, co je tu psáno, vypadá jako úplná pitomost, pravděpodobně je to proto, že jsem něco nepochopil, překroutil nebo si to špatně pamatuji. Za všechny chyby se předem omlouvám.)

Jednotné API pro instalaci softwaru

Firmy vyvíjející software chtějí mít vlastní instalátor, nezávislý na balíčkovacím systému, fungující stejně jako ve Windows. Tedy malý program, který uživatel spustí, on všechno nainstaluje, během toho kreslí obrázky, animuje video, ptá se uživatele na různé věci, kontroluje licence a čert ví, co ještě. Leckdo (třeba já) to nepovažuje za moc dobrý nápad, ale oni to prostě chtějí. (Příčin, proč to chtějí, je pravděpodobně víc, od prostého lpění na starých postupech až po fakt, že každé distro má svůj balíčkovací systém a připravovat od každé verze programu dvacet různých typů balíčků by otrávilo i mrtvého.)

Na konferenci jsme se tedy zabývali tím, jak tento nápad umožnit tak, aby napáchal co nejméně škod. Bylo rozhodnuto, že sestavíme oficiální API, které bude nezávislé na balíčkovacím systému. Jak konkrétně to bude vypadat a jak silná vrstva různých pomocných funkcí k tomu bude potřeba, není dosud jasné; v nejhorším případě vznikne druhý balíčkovací systém, zcela nezávislý na tom systémovém.

Zájemcům doporučuji k přečtení tento a tento blogpost Iana Murdocka (jeden z hlavních organizátorů LSB), kde se dosti detailně zamýšlí nad touto problematikou. Také si můžete prohlédnout webové stránky pracovní skupiny LSB pro řešení problému balíčků a instalátorů.

Začlenění Javy do LSB

Do standardu LSB v 4.0 by měla přibýt Java. K tomu je třeba stanovit, jaké chování interpreteru Javy se bude považovat za standard a jaké funkce budou garantovány. To není jednoduché, neboť v dnešní době existuje několik různých implementací Javy, které v důsledku různých extenzí, které si každý výrobce sám za sebe přidělal, už nejsou kompatibilní. Tvůrci aplikací psaných v Javě proto raději ke svému produktu rovnou přiloží i celé běhové prostředí Javy. Tento uzel bude třeba nějakým způsobem rozplést, buď standardizací holého základu (který ale bude těžké používat), nebo tím, že si vybereme určitá rozšíření (pak ale nevím, jak to budeme prosazovat).

Začlenění Pythonu

Součástí další verze LSB standardu bude interpreter Pythonu. Zde je situace trochu jasnější než u Javy, protože různých interpreterů není tolik. Bylo rozhodnuto, že standardizovat se bude originální interpret psaný v jazyce C (CPython), další alespoň prozatím ne. Bude jen třeba rozhodnout, které z mnoha rozšíření Pythonu jsou natolik profláknutá, aby se dala vložit do standardu. Zatím není zcela jasné, zda bude standard zahrnovat i binární rozhraní Pythonu směrem k C a zda by se měl standardizovat i jazyk jako takový (jeho syntaxe) nebo jen stanovit, že interpret musí být schopen bezchybně provádět nějaké konkrétní skripty.

Začlenění D-busu

Na konferenci bylo odsouhlaseno, že knihovna D-Bus, sloužící pro komunikaci mezi aplikacemi, je natolik rozšířená, že bude přidána do standardu LSB 3.2 jako volitelný standard.

Nové funkce z glibc

V rámci obvyklých aktualizací standardu budou do LSB 3.2 začleněny nové funkce, které se objevily v glibc. Přesný soupis najdete zde. Nejzajímavější je patrně rozhodnutí o přidání funkcí *at() a funkcí týkajících se služby inotify, které jsou sice velmi nové, ale velmi žádané.

       

Komentáře

[Filip Jirsák]

Ad instalační API a Java v LSB - řeší se nějak i knihovny Javy? Java je v současné době přesně v takovém stavu, kterému se snaží zabránit balíčkovací systémy, a který tak prosazují ti, co požadují instalační API - každá aplikace se stará o knihovny sama, takže nakonec máte v systému tu samou knihovnu (jar) mnohokrát, pokaždé s jinou aplikací, často se liší jen v setinkové verzi, navíc při updatu knihovny v mainstreamu se musí o update i v konkrétní aplikaci postarat autor aplikace.

[Bluebear]

Ad instalační API a Java v LSB - řeší se nějak i knihovny Javy?

To bohužel nevím; o tom, jak se v Javě používají knihovny, mám jen velmi mlhavou představu. Očekával bych, že nejdřív se bude řešit standardizace základního javovského runtimu s jeho nejvlastnějšími knihovnami, a pak případně to ostatní.

[trekker.dk]

Bylo rozhodnuto, že sestavíme oficiální API, které bude nezávislé na balíčkovacím systému.

Kam tohle API bude instalovat software? A co udělá, když soubor, který se má nainstalovat, již existuje?

[xkesh]

Kam tohle API bude instalovat software?

Přece do /Program Files/Company Label/Version/.

A co udělá, když soubor, který se má nainstalovat, již existuje?

Přepíše.

Nač vymýšlet něco nového, když tu máme osvědčené

[Bluebear]

V případě takového řešení bych to spíš viděl na /opt/third_party/Company Label/Version/.

A co udělá, když soubor, který se má nainstalovat, již existuje?

To by se při takové organizaci nemělo nikdy stát, a pokud přece, API by mělo odmítnout ten soubor přepsat, případně umožnit uživateli volbu (pokud je to možné).

[Bluebear]

To API by mělo komunikovat s balíčkovacím systémem, takže v ideálním případě by se měly všechny soubory nainstalovat tam, kam by je nainstaloval balíčkovací systém sám...

[Michal Vyskočil]

No nevím, raději bych, aby se tyto third-party věci dávali do /opt, jak stanovuje FHS.

[xkesh]

No nevím, raději bych, aby se tyto third-party věci dávali do /opt, jak stanovuje FHS.

Nebojte, jistě si budete moci vybrat distribuci, která to bude dělat právě podle vašeho gusta

[Michal Vyskočil]

Nevím, proč by se měla nějaká distribuce řídit mým gustem a ne standardy :-P

[Bluebear]

Nevím, proč by se měla nějaká distribuce řídit mým gustem a ne standardy :-P

A proč ne? V LSB, stejně jako kdekoli jinde, rozhodují lidé, a ti jsou ovlivnitelní. Doporučuji nastudovat dílo Nicola Machiavelliho a pustit se do toho.

[David Jaša]

... pokud bude vaše gusto odpovídat LSB. Jinak máte smůlu.

[xkesh]

... pokud bude vaše gusto odpovídat LSB. Jinak máte smůlu.

To si povíme, až se to dohodne... a přesto nebude dodržovat

[trekker.dk]

No a v případě že Next-Next-Finish aplikace bude chtít přepisovat soubory, co se stane potom? Nevím jak jinde, ale dpkg v takovém případě instalaci ukamžitě ukončí a NNF se tím pádem nenainstaluje.

A pokud ten soubor bude shodou okolností nějaká knihovna (.so) s nekompatibilní verzí, tak jste v háji, protože buď nebude fungovat NNF nebo zbytek systému. A už musíte buď dokopat výrobce ke změně umístění toho souboru (ale to vám dpkg taky nedovolí nebo aspoň bude nadávat) nebo k jeho přejmenování.

Máte v plánu, jak vyřešit tohle?

[trekker.dk]

Oops, přehlídl jsem, že jsi už odpovídal:

To by se při takové organizaci nemělo nikdy stát, a pokud přece, API by mělo odmítnout ten soubor přepsat, případně umožnit uživateli volbu (pokud je to možné).

A když to možné nebude?

[Bluebear]

A když to možné nebude?

Podle mého názoru by se měla v takovém případě ohlásit chyba a přerušit instalace. Pokud byly provedeny nějaké změny, vrátí se zpět.

Uvědomuji si, že "vrácení zpět" není jednoduchá úloha, ale řešit se to dá, například:

1. API bude registrovat změny a poskytne funkci, dejme tomu, rollback(), která automaticky všecko vrátí. To je ten nejměkčí způsob, spoléhající na to, že autor instalátoru bude slušný a všechny změny bude opravdu dělat skrze to API a ne mimo. (Což se do jisté míry dá staticky ověřit, například ujištěním, že binárka instalátoru se linkuje jen proti našemu API a proti ničemu jinému.)

2. Celá instalace bude probíhat v nějakém druhu karantény (sandboxu), například pomocí chrootu nebo vrstveného filesystému (nemůžu si vzpomenout, jak se ten nástroj jmenuje, ale vy mi rozumíte, že? ), takže když instalátor neuspěje nebo se zhroutí, celý obsah karantény se zahodí a systém zůstane nezměněn.

[trekker.dk]

Možná, že to vrácení zpět bude jednodušší úloha, než přesvědčit výrobce programu, že kolize v názvu souborů je chyba

[Filip Jirsák]

Uvědomuji si, že "vrácení zpět" není jednoduchá úloha, ale řešit se to dá, například:

Je to jednoduché.

2. Celá instalace bude probíhat v nějakém druhu karantény (sandboxu), například pomocí chrootu nebo vrstveného filesystému (nemůžu si vzpomenout, jak se ten nástroj jmenuje, ale vy mi rozumíte, že? ), takže když instalátor neuspěje nebo se zhroutí, celý obsah karantény se zahodí a systém zůstane nezměněn.

A přesně takhle to dělá Gentoo. Dokonce není potřeba žádný chroot, prostě instalační skript se na začátku zeptá na prefix cesty, kam má instalovat, a na konci se přesunou soubory na to samé umístění bez prefixu.

[David Jaša]

Díky za reportáže. Sám nejsem informatik a používám 3rd party softy, které z principu nikdy F/OSS nebudou a docela chápu, proč dnes nejsou pro linux k dispozici. Doufám, že právě tato iniciativa s tím něco udělá...

[Josef Kufner]

Javu néé... Jak takovej paskvil může někdo zahrnout do LSB?

A s tím nebalíčkovadlem to taky vypadá celkem zvrhle. Nebylo by jednodušší jim dát nástroj, který vyrobí těch pár balíčků pro nejpoužívanější balíčkovací systémy a jeden tarball?

[Bluebear]

Nebylo by jednodušší jim dát nástroj, který vyrobí těch pár balíčků pro nejpoužívanější balíčkovací systémy a jeden tarball?

Bohužel vyrobit takový nástroj není nic jednoduchého, pokud chcete, aby to vyrábělo balíčky přesně odpovídající různým distribucím. V podstatě jediný známý způsob, jak to udělat spolehlivě, je nainstalovat si příslušné distribuce a sestavit každý balíček na každé z nich. Což je proveditelné, pokud máte serverovou farmu.

SuSE/Novell nedávno spustil volně přístupnou službu "OpenSuSE Build Service", kde je možné si přes web uploadovat své zdrojáky k nám, na našich serverech se to sestaví a dostanete přímo hotová RPMka (nejen pro OpenSUSE, ale tuším i pro RedHat a snad ještě pár dalších distribucí). Jenže tohle komerčním firmám nepomůže, protože si dost dobře nemohou dovolit poslat své zdrojáky na cizí server.

[anicka]

Na druhou stranu, v nejblizsi dobe bude BS zcela otevrene a nikdo nikomu nebude branit, aby si jej rozjel na svych vlastnich strojich.

[xkesh]

Hleďme, tudy se ubírá vývoj.

[Josef Kufner]

Serverovou farmu? Vždyť distribucí pro které má smysl balíčky dělat je pár (šest?) a na jeden obyčejný disk se to vejde. Stačilo by udržovat poslední stable těch několika zajímavých distribucí s potřebnýma knihovnama, což není problém. Pak stačí akorát mít script, který po nabootování a automatickém přihlášení stáhne aktuální zdrojáky, zkompiluje je, ubalí balíček, spustí sérii testů, jestli to funguje a nakonec rebootne do dalšího distra. Víceméně jde jen o to, aby výsledný balíček byl zkompilován se správnýma verzema knihoven a měl rozumné závislosti. Přes noc by to vcelku obyčejný počítač mohl v pohodě stihnout.

[Spike]

Nač rebootovat? Virtualizace nebo chroot mi přijde pohodlnější. ;)

[Bluebear]

Jistě, to všechno jde také, záleží jen na tom, v jak velkém měřítku to chcete provozovat. Na jeden nebo několik málo menších balíčků by jedno PC asi stačilo, ovšem pokud hodláte buildovat takové obludy, jako OpenOffice, Xka a podobné, asi by bylo lepší mít těch počů víc.

[Michal Vyskočil]

Až na uživatele LFS a Gentoo jsou toto zrovna balíčky, jejich kompilaci necháváme na svých distributorech

[David Jaša]

A já myslel, že se tady bavíme o instalaci softů, které distributoři nikdy kompilovat nebudou a toto byl jenom příklad.

[Brabi]

O podobný instalátor se už snaží projekt Autopackage - www.autopackage.org