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

[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