RPM benefits ?

22.9.2008 14:01 | Přečteno: 1202× | poslední úprava: 22.9.2008 14:02

Ohledně balíčkovacích systémů jsem tzv pole neorané. Přečetl jsem si tisíc flamů po internetu, desítky popisů v encyklopediích a různých wiki, ale odpověď na mou otázku jsem nedostal. Dnes jsem narazil na tento slade: RPM benefits

Jako uživatel suse a ubuntu znám rpm a deb pouze z uživatelského hlediska. Porovnám-li ubuntu/deb a suse/rpm, pak jedine prakticke závěry, ktere jsem schopen vyvodit jsou, ze v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.

Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.

V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm. Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva. Což je další výoda pro deb.

Jedina vyhoda, kterou jsem u rpm zaznamenal je delta-rpm, ovšem to je asi susí specialitka, mimo to update suse je i tak mnohem zdlouhavejší nez update ubuntu.

Zajímalo by mě tedy, v čem jsou takové výhody rpm, že jej využívá mnohem více distribucí než deb?

Asi jsem natvrdlý, neb mi to nějak nedochází, a nebo je to absencí praxe, kterou ovšem nevyčtu po manuálech.

       

Komentáře

[Käyttäjä 11133]

1. Dneska snad nikdo rpm balíky nedělá pomocí rpmrebuild, ale používá na to /usr/bin/build

2. Pokud dojde k problému při x86_64 s přeinstalováním půlky systému tak je to prostě na bugzillu.

3. To že v závislostech debianích balíčků by byl menčí bordel kvůli tomu, že by záviseli jen na balíčcích samotných je pěkná hloupost Výhoda debianu je v tom, že má policy takové jaké má a tedy, že v jeho repositářích může růst každý balíček a nedochází tam tak k situacím jako například v openSUSE, kdy polovina balíčků roste v Packmanovi, který neumí při změně závislosti libA přebuildit všechny aplikace které na libA závisí. Proto musí aktualizace hlídat balíkáři, kdyby byly ty balíčky součástí distribuce, tak by si to ohlídal autobuild a balíčky by tak byly konzistentní. A ani závislosti jen na balíčcích k ničemu nepomůžou... Mimochodem ono se to automatické registrování závislostí dá vypnout a pak to může být přesně jako v debianu...

[michich]

v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.

Na druhou stranu možnost souborových závislostí zase zjednodušuje práci vývojáře. Výhoda není tak jednoznačná na jedné ani druhé straně.

Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.

Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.

V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.

Já jsem četl pravý opak. Sám dělám ale pouze RPM balíčky, takže nemůžu srovnávat.

Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.

Ne, žádná taková potřeba neexistuje, to by byla pitomost.

[Mr_Newman]

Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.

Ony ty nejpoužívanější 32bit balíky mají verzi pro architekturu AMD64. Rozdíl je IMHO v tom, že Debian udělá změnu AMD64->i586 pouze na výslovné přání uživatele. RPM distro tu změnu na výslovné přání neudělá. Výsledek je de-facto stejný, jen mi přijde, že RPM musím kvůli tomu více hlídat pokaždé, když něco instaluju.

[sheeryjay]

Ony ty nejpoužívanější 32bit balíky mají verzi pro architekturu AMD64.

Skype, flash, java (v novější době už možná)?

[David Šmíd]

ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.

To je naopak velmi nedoporučované. Vše v RPM samozřejmě závisí na uživatelském nastavení, žádné takové "absolutní povinné cesty" neexistují.

V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.

Nevím, ve vytváření deb balíčků se nevyznám. Nicméně k vytvoření RPM vám stačí jeden .spec soubor (něco jako recept na sestavení) a jeden soubor se zdrojovými kódy (tarball). To mi připadá velmi přehledné.

Je třeba mít na paměti, že množina distribucí používajících RPM je značně heterogenní. DEB balíčky byly donedávna výsostnou doménou Debianu, to spoustu věcí zjednodušuje.

K výhodám RPM: co třeba rollbacks ? To se může docela hodit.

---

[Mr_Newman]

Rollbacks?

Výborně. první vlaštovka, kterou jsem hledal. DEB nemá alternativní řešení k rollbacks? Obě varianty pokud vím umožňují uložit databázi nainstalovaných balíků do souboru, takže jediná výhoda rollback-u je v tom, že nemusím ty "soubory" vytvářet sám?

[michich]

rollbacks nejsou moc dobrý příklad. --repackage byl ošklivý hack, skoro nikdo to nepoužíval, nikdy to nebylo pořádně podporované, a v RPM 4.6 už to vůbec není.

[Heron]

To řešíte teoreticky, protože chcete vědět jak to funguje zevnitř, nebo jako vývojář? Za sebe, jako uživatele balíčkovacích systémů vím jedno: všechno stojí a padá s kvalitou balíčkáře. Vadný balík, jedno jestli rpm, deb, zdrojáky, udělá bordel bez ohledu na balíčkovací systém..

[bibri]

... všechno stojí a padá s kvalitou balíčkáře. Vadný balík, jedno jestli rpm, deb, zdrojáky, udělá bordel bez ohledu na balíčkovací systém..

Přesně tak.

[Mr_Newman]

Ano. řeším to jako user, tedy teoreticky. Primární vliv lidského faktoru si uvědomuji. Zajímá mě rozdílnost principů obou přístupů. Ty jsem nikde nevyčetl.

[Aleš Kapica]

Jsi natvrdlý, hloupý a navíc líný. Protože jinak bys neměl za málo si přečíst na tomto portálu články a blogposty kde se tohle rozebíralo.

[Mr_Newman]

každý nemůže být génius

[belisarivs]

Mne na rpm chybi urovne zavislosti jako v Deb.

Cili neco jako - depends, recommends, suggests.

Jinak mi tvorba rpm baliku tezka nepripadne. Spec soubor je v podstate skript, ktery ma syntaxi jak BASH a dela se s nim v pohode.

Ale ank debiani baliky nejsou tezke. Obzvlaste kdyz zdrojaky pouzivaji configure a make. To pak staci dh_make (podle toho jak moc rychle a ciste je potreba balik vytvorit).

[Käyttäjä 11133]

Hmm...

Mne na rpm chybi urovne zavislosti jako v Deb.

Cili neco jako - depends, recommends, suggests.

Škoda, že máme každý jiné suse :D Software Management/Dependencies

[belisarivs]

Hm. Dobre. Ja usoudil, ze kdyz v Yastu neco takoveho neni, tak ze to neumi RPM.

Pri tvorbe baliku jsem to jeste nepouzival.

Mea Culpa. Denni davku blbosti jsem si timto, doufam, vybral.

[David Šmíd]

Takže jak vidno, v RPM ti už nic nechybí (slabé závislosti už RPM skutečně umí). Otázka je, jestli tuto vlastnost dostatečně využívají nadstavby pro správu balíčků (apt, zypp, yum, urpmi, smart, ...).

Jsem rád, že se tahle diskuse nezvrhla ve flame. Ono totiž skutečně nezáleží na tom, jestli vytváříte DEB nebo RPM - obojí má přibližně stejné možnosti. Hlavní je, jak dobře to děláte.

---

[Rezza]

Presne! Ac trebas u Fedory je review proces celkem slozity, tak se nekdy clovek divi kolik chyb muze nasekat v jednom jednoduchem par radkovem SPEC fajlu. A proste sam to nevidi. A proste zavisi na kvalite balicku, pokud ten je blby, tak uz to nic nezachrani...

[disorder]

v debiane je jednoduchy -- musi prejst cez new queue (a moc ludi na kontrolu nie je)

ale naopak sa velmi vyuziva lintian