LSB chce řešit nejednotnost instalace software

Projekt Linux Standard Base (LSB) se snaží ve spolupráci s organizací Free Standards Group vyřešit problém nejednotnosti způsobu instalace software mezi distribucemi tak, aby mohl být Linux dodavateli software považován jako jedna platforma. Chtějí toho dosáhnout vytvořením jednotného API, které bude zakrývat odlišnosti mezi rpm, dpkg, yum a dalšími. Více se dozvíte na Linux-Watch.

3.1.2007 19:46 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[neveceral]

konečně, už aby to tu bylo

[Ctirad Feřtr]

V druhé fázi potom dojde na jednotné API, které bude zakrývat odlišnosti mezi různými verzemi knihoven následované API, které bude zakrývat odlišnosti mezi různými knihovnami a to i tehdy, pokud vůbec nebudou nainstalované a hned v závěsu API, které bude zakrývat odlišnosti mezi různými jádry. V poslední fázi potom vznikne API, které bude zakrývat odlišnosti mezi různými procesory.

[Luboš Doležel (Doli)]

V článku se píše, že toto API bude omezeno jen na základní potřebné minimum. Oni se nesnaží sjednotit balíčkovací systémy.

[Jozef Vondrák]

Neřvi hned!

[Ctirad Feřtr]

Příště tam přidám ještě hodně vykřičníků a velký červený písmena

[Max]

Pokud by to šlo, tak ty červený písmena bych chtěl vidět hned :D
Zdar Max

[trekker.dk]

Toho bych se nebál - spíš jim jednotně dojdou síly, protože bude málo lidí, kteří by se o tohle chtěli starat.

[Bluebear]

Toho se taky bojím.

Přesněji řečeno, nebojím se toho package managementu, to myslím, že zvládneme. Horší je podle mého názoru značný nárůst počtu knihoven, které jsme se rozhodli standardizovat.

[trekker.dk]

Tak package management je ve své podstatě jednoduchý - ve většině distribucí už je to hotové.

Problém bych v tomto ohledu viděl spíš v tom, že se může stát, že konkrétní balíčkovací systém nebude umět to, co po něm budete chtít - například .deb těžko donutíte ke stažení zdrojových kódů, které nejsou v distribuci, a následného překladu. Jinak řečeno v Debianu nepůjde udělat emerge (i když tu a tam by se to hodilo... ) Takže to API může pokrývat jenom funkce, které fungují ve všech podporovaných balíčkovacích systémech (a nebo musíte dokopat vývojáře, aby ty funkce dopsali)

Horší je podle mého názoru značný nárůst počtu knihoven, které jsme se rozhodli standardizovat.

K závislosti na "LSB"... no že bych byl odvázaný z myšlenky, ža nainstaluju všechno a potřebovat budu jenom půlku, ale budiž. Je to lepší, než kdyby v té LSB závislosti byla jenom půlka knihoven, které jsou potřeba.

Horší je to, že se maintaineři distribuce xyz můžou rozhodnout, že oni potřebujou jinou verzi knihovny libabc, protože v té vaší není funkce uvw(). Pak se toho chytí ostatní distra a najednou zjistíte, že někdo používá tuhle verzi, někdo jiný jinou a pár ostatních tu vaší. No a pak se na to můžete ... maximálně dát neposlušným distrům nálepku "not LSB compliant"

[Aleš Kapica]

například .deb těžko donutíte ke stažení zdrojových kódů, které nejsou v distribuci, a následného překladu.

Nerad bych se mýlil, ale řekl bych že nemáte pravdu, protože pokud nejsem za proxy, tak mi normálně během instalace - pokud je to třeba - apt balíky které vyžaduje stáhne a překompiluje.

[Aleš Kapica]

Teda bych to upřesnil.. stáhne si co ten balík potřebuje a zpracuje. Příkladem je např. msttcorefonts

[trekker.dk]

To asi jo, ale odhadl bych, že je to součástí některého ze skriptu před nebo po instalaci.

Já jsem spíš mluvil o něčem takovém, že aptu řeknu, kde má hledat zrojové kódy od nějakého programu, a on při každém upgrade zjistí, jestli není k dispozici nová verze. Když ano, tak ji stáhne, rozbalí, přeloží a nainstaluje. To asi nejde...

[Aleš Kapica]

Jde. Přesně takhle je třeba dělaný zdrojový balík pro openoffice.org.

[anicka]

Mozna by stalo za to premluvit BlueBeara, aby o tom napsal nejaky blog. On v tom Berline byl a jeho historky jsou dost hruzostrasne

Ale ono neni divu... tohle IMHO proste nikdy nemuze fungovat dobre. Dokonce ani jenom v RPM based distribucich ne

[Bluebear]

To udělám rád, pokud bude zájem, ale musím nejdřív požádat o dovolení u nás, abych omylem neprořekl důvěrnou informaci nějaké firmy. Přece jen tam bylo hodně lidí z různých společností a probíraly se jejich plány do budoucna.

[br]

To udělám rád, pokud bude zájem

zájem určitě bude/je :)

[xkesh]

Bohužel to patrně dopadne tak, že organizace vznikne, ale její standardy nebude nikdo respektovat, především ti nejsilnější hráči z distribucí.

Standard může prosadit pouze někdo s autoritou, a to v našem světě ještě pořád znamená síla (v jakékoliv podobě). I k dohodě musí někdo její účastníky dotlačit. Uživatelé a vývojáři (= fandové jednotlivých distribucí) ani dodavatelé software to ale nebudou.

Až nějakou distribuci koupí MalýMěkký, tak uvidíte, jak se "dělá" standard

[Ctirad Feřtr]

Mě by hodně zajímalo, jak by takový standard měl vypadat a jestli vůbec někdo, kdo podobné projekty vymýšlí, vůbec tuší, co znamenají zkratky API, ABI a jak fungují dynamické knihovny.

[Bluebear]

jestli vůbec někdo, kdo podobné projekty vymýšlí, vůbec tuší, co znamenají zkratky API, ABI a jak fungují dynamické knihovny.

Tuší. Komise LSB jsou lidé z oboru, řada z nich pracuje pro firmy jako je Intel, SAP, a samozřejmě Novell. A zrovna o dynamických knihovnách (a jak je správně standardizovat) probíhala v Berlíně dost velká technická debata.

[Michal Vyskočil]

Stačí se podívat na LSB face-to-face. Na tom summitu byli i lidé kolem distribucí (kouzelné jméno má Paul Nasrat z RedHatu ), lidé z Intelu a Real Networks, SAPu, nebo AMD.

Takže předpokládám, že ti lidé o API, ABI a dynamických knihovnách aspoň jednou slyšeli

[Michal Kubeček]

Původně jsem si myslel, že kvůli tomu vznikl UnitedLinux. Ale postupem času jsem začal mít pocit, že jediným smyslem toho projektu bylo omezit hegemonii Red Hatu a v okamžiku, kdy hegemonie Red Hatu vzala zasvé, vzal zasvé i United Linux… :-)

[Martin Lebeda]

Je to smutné, ale musím s tímhle názorem souhlasit. Jak kdosi již řekl: "nejlepší vyjednávací argument je vlastní miliónová armáda".