RPM vs. DEB šílenství

3.6.2008 11:57 | Přečteno: 5068×

Na fóru sem nalezl velmi častý dotaz proč ještě někdo používá to zaostalé RPM, když balíčky Debianu a Gentoo jsou mnohem lepší. Když ale člověk položí otázku proč, dostane jen obvyklou bezobsažnou odpověď o Dependecy Hell. Proč jsou neustále šířeny tyto absurdní FUDy. Podíval jsem se tedy na problematiku RPM vs. DEB blíže.

Principielní rozdíl mezi RPM a DEB je v závislostech. Debian ke svým balíčkům přistupuje překvapivě "proprietárně". Závislosti jsou řešeny jen a pouze vazbou na jiné balíčky a tak je DEB velmi špatně přenositelný na jíný systém. Viz vztah Debian a Ubuntu. Ano, pověstné w32codecs ubunťáci cpou do systému z Debianu, ale kompatibilita mezi dvěma Debian based distry je dána jen záměrem/nezáměrem tvůrce balíčku, definováním závislostí a shodným pojmenováním. Přístup Debianu k ostatním distrům je v tomto případě stejně "vstřícný" asi jako Microsoftu.

RPM řeší závislosti vazbou na soubory i balíky. Je tedy mnohem snazší zprovoznit cizí balík, neb je jasné, na kterých souborech, knihovnách a jejich verzích závisí. V tomto ohledu je přístup RPM mnohem více sjedocující napříč distribucemi a má mnohem blíže k přenostelnosti a otevřenosti.... Když se tak nad tím zamyslím, ani se nedivím, proč původně byl záměr standardizovat do LSB jen RPM a poč Debianisté řvali jak raněný tur....

       

Komentáře

[Michal Čihař]

Ano, závislost na jménu souboru je skvělá věc, bohužel je spousta věcí kde se to nedá použít (verzované závislosti, moduly pro Perl nebo Python, atd.) a dokud RPM distribuce nebudou mít stejné názvy balíčků, tak v tom stejně není žádný rozdíl od Debianu .

[Michal Čihař]

...a nakonec, když chce člověk udělat univerzální RPM, tak v něm má tolik ifů, že se z toho zblázní (viz třeba gammu.spec).

[Käyttäjä 11133]

A proto taky RPM může záviset třeba na jaderných symbolech,..

[Aleš Kapica]

Očividně jste nepochopil jak deb balíčkovací systém funguje a jaký je rozdíl mezi ním a rpm. Než bych se opakoval, raději přihodím  link na kapitolku ve wikibooks - Instalační balíčky.

[extender]

článek Debianisty bude skutečně objektivní

[Aleš Kapica]

Začínal jsem na Mandrake a kromě toho občas řeším i SUSE, takže bez poznámek prosím.. Ostatně, vzhledem k tomu že již nějaký čas se rpm nevěnuji, ponechal jsem i "opravu" mého původního článku na wikibooks beze změny, přestože s ní nesouhlasím. Netvrdím že by balíčkovací systém debianu byl dokonalý, nicméně nejenom mě vyhovuje více a pro řadu lidí to byl i důvod pro změnu distribuce.

[extender]

Tak to prrrr. Něvěděl jsem, že je to tvoje/vaše. Je to poznat z textu a z toho, jaká je oběma balíkům věnována pozornost.

Jenže on tím důvodem nebyl DEB ale apt, což IMHO s konstrukcí DEB jako takovou příliš nesouvisí. Pro RPM dneska existuje výkonný libzypp, který náročnější závislosti RPM řeší brutálně rychle.

[Aleš Kapica]

Ano. Tím důvodem byl apt. Nejprve jsem objevil synaptic a apt4rpm (proto jsem ostatně Synaptic lokalizoval), jenže mě vytáčelo kolik dat se pokaždé stahuje jen proto aby systém zjistil že žádný nový balík v repository není. Teprve pak jsem objevil jednoduchost a efektivitu aptu nad deb balíčkovacím systémem. Nejprveá však na Ubuntu - to ještě Petr Tomeš o této distribuci neměl tucha. U toho mi však vadilo, že to není roll-on distribuce (u mandrake jsem používal vždy balíky z cookera) a nebavilo mě hlídat si kdy vychází nová distribuce, jen proto že mě zajímá novější verze nějakého balíku.

[extender]

což ale opět není dáno vlastností DEB a nevlastností RPM. Roll on lze udělat na obou. Znova opakuji. Mluvím o kvalitách návrhu typu balíku, né o distribuci jako celku.

[Aleš Kapica]

Z trabanta který používá gumy GoodYear taky nebude Formule 1. Mě deb vyhovuje svou jednoduchostí.

[extender]

jednoduchost a komplexnost jsou jaxi neslučitelné. O tom se tady přece nediskutuje

[Aleš Kapica]

Ne? Tak o čem? Že z vašeho pohledu komplexní rpm má být lepší než jednoduchý deb? Víte co, trochu se v těch systémech pohrabte, udělejte si pár balíků, a pak můžeme dál pokračovat.

[extender]

Ne? Tak o čem? Že z vašeho pohledu komplexní rpm má být lepší než jednoduchý deb? Víte co, trochu se v těch systémech pohrabte, udělejte si pár balíků, a pak můžeme dál pokračovat.

četl jste vůbec můj blogpost:

V tomto ohledu je přístup RPM mnohem více sjedocující napříč distribucemi a má mnohem blíže k přenostelnosti a otevřenosti....

Asi ne...

[happy barney]

no, tak práve vlastnoť robiť závislosti na súbor (a nie na balík) je vec, ktorá celý systém rozbíja (a je prenositelna asi ako windows - krabica sa preniesť dá). btw, bola tam dodaná, pretože zamestnanci redhat-u sa v slovníku nedostali po slovo "alternatíva".

[JKK]

Možná jsem hloupý, ale tohle mi budete muset vysvětlit!

no, tak práve vlastnoť robiť závislosti na súbor (a nie na balík) je vec, ktorá celý systém rozbíja (a je prenositelna asi ako windows - krabica sa preniesť dá). btw, bola tam dodaná, pretože zamestnanci redhat-u sa v slovníku nedostali po slovo "alternatíva".

Mám balíček DEB z debianu. Pokusím se ho nainstalovat na moji Deb-based ditribuci. Mohou nastat jen dva případy:

1) balíček odkazuje na balíčky, které se v mé distribuci jmenují stejně jako v Debianu a balíček se nainstaluje.

2) balíček odkazuje na balíčky, které se jmenují jinak, než balíčky v mé distribuci a jsem v prdeli.

Mám-li RPM, nemusím znát jméno balíčku, solver prohledá balíky, najde si potřebné knihovny, vyrobí si závislosti a balík nainstaluje. Tenhle princip mi přijde IMHO univerzálnější, ne?

no, tak práve vlastnoť robiť závislosti na súbor (a nie na balík) je vec, ktorá celý systém rozbíja (a je prenositelna asi ako windows - krabica sa preniesť dá). btw, bola tam dodaná, pretože zamestnanci redhat-u sa v slovníku nedostali po slovo "alternatíva".

[Filip Jirsák]

Mám-li RPM, nemusím znát jméno balíčku, solver prohledá balíky, najde si potřebné knihovny, vyrobí si závislosti a balík nainstaluje. Tenhle princip mi přijde IMHO univerzálnější, ne?

Ne, oba dva principy dělají trochu něco jiného, než by dělat měly, a každý to dělá trochu jinak. Závislost u softwaru znamená, že potřebuji třeba nějakou knihovnu implementující něco s nějakými vlastnostmi. To něco může být třeba SSL dané interfacem openssl a požaduji třeba implementaci protokolu SSL 2. Nebo to může být třeba Java Runtime Environment ve verzi alespoň 1.5.

Jeden balíčkovací systém to řeší závislostí na balíčkách (takže vychází z předpokladu, že tu danou věc může implementovat právě jeden balíček). Druhý to řeší (mimo jiné) závislostí na souborech (takže vychází z předpokladu, že přítomnost nějakého souboru někde znamená přítomnost implementace). Asi nejčistší řešení by bylo, kdyby o sobě každý balíček říkal, co poskytuje, a každý balíček by si mohl říci, co potřebuje. Jenže to je zároveň velmi pracné na údržbu, protože to budete muset složitě definovat i u balíčků, které víc implementací normálně nemají.

[Käyttäjä 11133]

kdyby o sobě každý balíček říkal, co poskytuje

Myslíš něco jako tohle?

mantisha:/home/marek # rpm -qp --provides madwifi-kmp-default-0.9.4_2.6.25.4_9.1-1.i586.rpm
madwifi-kmp = 0.9.4_2.6.25.4_9.1
ksym(_ath_hal_attach) = ea10ec7e
ksym(ath_hal_computetxtime) = 770fb583
ksym(ath_hal_detach) = 9616c7c2
ksym(ath_hal_getuptime) = 2d2cd95d
ksym(ath_hal_getwirelessmodes) = 88074857
ksym(ath_hal_init_channels) = e8a4894a
ksym(ath_hal_memcmp) = 93cb6276
ksym(ath_hal_memcpy) = a0fa8bf4
ksym(ath_hal_memzero) = 4dce8c00
ksym(ath_hal_mhz2ieee) = 62f37fda
ksym(ath_hal_printf) = 5b1d4795
ksym(ath_hal_probe) = 51a400eb
.
.
.

Provides je generované automaticky z binárky. Avšak může být i doplněno ručně pomocí Provides:, poté se provede sjednocení množin z automatické registrace provides a těch ručně definovaných provides. Stejně tak se nakládá i s requires.

[Filip Jirsák]

Myslel jsem to na trochu vyšší úrovni abstrakce. Ona funkce „poskytuje“ nemusí zanmenat jenom to, že poskytuje nějakou knihovní funkci, ale třeba také nějakou funkcionalitu pro užiavtele („přehrávání MP3“), nebo danou funkci nějak implementovanou (např. funkce „http_download“ může být implementována bez nebo s podporou HTTPS, s nebo bez podpory proxy atd.).

[MJ]

Ona ta úroveň abstrakce ale už dávno existuje – třeba v Debianu se k tomuto účelu běžně používají virtuální balíčky a každý skutečný balíček pak může říci, které virtuální poskytuje.

[Filip Jirsák]

Což znamená, že problém zmíněný v blogu není problém technologie Debianí balíčků, ale toho, jak jsou vytvářeny konkrétní balíčky. A ty jsou vytvářeny tímto způsobem nejpíš proto, že se nikomu nevyplatí se vším se dělat jako s virtuálními balíčky.

[MJ]

"Dělat se s něčím jako s virtuálními balíčky" v neznamená nic jiného, než dohodnout se na tom, že bude existovat nějaký interface, který se bude nějak jmenovat a nějak chovat. A bez toho to bohužel nejde – pokud to budete dělat živelně, brzy vznikne chaos.

Můj příklad s /usr/bin/git níže naznačuje, že pokud chcete používat globálně jednoznačné identifikátory (ať už jména balíčků nebo třeba souborů), musí existovat nějaký proces, který jim určuje globálně jednoznačnou sémantiku. Tento proces může vypadat různě – ať už jako centrální repository všech balíčků (Debian), nebo jako nějaký hierarchický systém (někdo mi přidělí nějaký prefix, muže to být třeba doména v DNS, a já pak mohu definovat identifikátory začínající tímto prefixem).

[MJ]

Mám-li RPM, nemusím znát jméno balíčku, solver prohledá balíky, najde si potřebné knihovny, vyrobí si závislosti a balík nainstaluje. Tenhle princip mi přijde IMHO univerzálnější, ne?

Do té doby, než se ve světě vyskytnou dva balíčky, které obsahují stejně pojmenovaný soubor

To se ale v praxi bohužel stává – například /usr/bin/git může patřit buďto k version control systému GIT, a nebo ke GNU Interactive Tools. Pak se celý systém závislostí na souborech s velkým řinkotem rozbije.

[Käyttäjä 11133]

Konflikty?

[MJ]

Nepomohou. Sice nemohu mít oba balíčky nainstalované, ale když si někdo objedná závislost na /usr/bin/git, balíčkovací systém neví, který z těch dvou balíčků nainstalovat.

[Käyttäjä 11133]

Ale ví, protože ten kdo si objedná závislost /usr/bin/git konfliktí s tím balíčkem, který obsahuje ten /usr/bin/git, který nechci. Je to sice ošklivá konstrukce, ale když žádnou lepší nemáme...

[MJ]

Tato konstrukce je nejen ošklivá, ale hlavně problém neřeší: nemohu přeci vědět, které všechny (stávající i budoucí) balíčky budou tento soubor obsahovat.

[Käyttäjä 11133]

No jasně, já vím, že nemůžeš. Chtělo by to vymyslet nějakou lepší. Ale nedokážu si představit nějakou jednoduchou konstrukci tak, aby se dala aplikovat v systému, který není centralizovaný. Debian má tu výhodu, že má obrovské centralizované repozitáře, u většiny RPM distribucí tohle bohužel neplatí.

[MJ]

Jak už jsem psal, řešit se to dá třeba hierarchickými jmény.

Například: Napsal jsem knihovnu libpci, tak ji umístím do svého podstromu hierarchie. Přidělím ji tedy jméno mj.ucw.cz/libpci/3.0. Ostatní pak vědí, že chtějí-li záviset na mé libpci, mohou se odkázat na toto jméno.

Případně to jméno dokonce může být URL souboru s nějakými metadaty o balíčku, kterými formálně popíšu, co je takový balíček zač – tedy třeba na existenci jakých souborů se všichni mohou spolehnout (bude mezi nimi knihovna, ale už mezi nimi asi nebudou init-skripty [kdyby libpci nějaké měla], protože ty jsou závislé na distribuci a mohou se v různých instancích balíčku lišit).

[Aleš Kapica]

Debian má tu výhodu, že má obrovské centralizované repozitáře, u většiny RPM distribucí tohle bohužel neplatí.

To je ale pěkná hloupost. Debian má právě výhodu že umožňuje mít decentralizované repository.

[extender]

jako že ve dvou různých repozitářích je stejný balíček se stejným jménem ale jiným obsahem?

[Aleš Kapica]

Jo. To může být. Proto se taky existuje možnost nastavit Aptu vhodnou policy. Ale chápu že to neznáte, protože o něčem podobném pro rpm nevím (netvrdím, že neexistuje).

[Pavel Stárek]

Pro rpm (tedy spíš pro jeho nadstavbu Yum) existují dva pluginy které tohle řeší: yum-priorities (nastavení priorit repozitářů - repo s priority=1 má nejvyšší prioritu), a yum-protectbase.

[Kyosuke]

Tak minimálně jednoduchou prioritu repozitářů ZYPP v SUSE umí sám. Víc jsem zatím nezkoumal.

[belisarivs]

Mám balíček DEB z debianu. Pokusím se ho nainstalovat na moji Deb-based ditribuci. Mohou nastat jen dva případy:

1) balíček odkazuje na balíčky, které se v mé distribuci jmenují stejně jako v Debianu a balíček se nainstaluje.

2) balíček odkazuje na balíčky, které se jmenují jinak, než balíčky v mé distribuci a jsem v prdeli.

Muze nastat vice moznosti. Napr. konflikty verzi.

Ale taky v deb lze nastavit promenna "Provides". Tzn, mas balik mplayer a pak mas balik treba Ogmrip. Ogmrip ma jako zavislost mencoder.

A balik mplayer ma promennou "Provides: mencoder". Tzn. neinstalujes zadny balik mencoder ale pouze mplayer a zavislosti jsou presto splneny.

[David Jaša]

Tak teda k té přenositelnosti: deb je velmi dobře přenosný na úrovni zdrojových balíků. O RPM jsem si to taky myslel, dokud jsem se nepodíval na ten .spec od gammu, co ukazoval Michal Čihař na začátku diskuse. :-P

[Käyttäjä 11133]

Jenže to nemá nic společného s RPM, ale s tím, že jiné distribuce mají jiné package convention. Třeba openSUSE háže KDE3 balíky do /opt/kde3. Pokud to jiná RPM distribuce dává jinam, tak je poněkud logické, že se tam musí dát nějaká podmínka. Nebo musí existovat nějaká globální proměnná ${KDE3_ROOT_DIR}, která by byla implementovaná ve všech RPM distribucích. Stejně tak naming convention se liší. V openSUSE ají knihovny prefix lib, python moduly python-. A není to způsobeno tím, že by to byla chyba RPM, ale tím, že každá distribuce má svoje specifika pro určité věci.

[David Jaša]

Jasně že jsou přenosné díky stejným package/naming conventions. Nicméně to popírá hlavní extenderův "argument" tohoto vlákna.

[Käyttäjä 11133]

Asi tak.

[Aleš Kapica]

Marku ty bys měl pomlčet. Když jsme se poznali, horoval jsi pro gentoo, pak pro suse. Co bude příště nevím, ale já už v době kdy jsme se poznali zakotvil u debianu a pořád ho k plné spokojenosti používám.

[Käyttäjä 11133]

Prosím? Kvůli tomu, že jsem několikrát změnil distribuci si nemůžu povzdechnout nad objektivitou článku? Tak to potěš koště, kam se to ještě dostaneme?

Navíc já pro Gentoo nikdy nehoroval, já ho prostě používal.

[Aleš Kapica]

Je to wikibooks, o objektivitu je postaráno tím, že každý - včetně tebe - může text upravit tak aby byl objektivnější (pokud se jako takový nezdá). Pokud však považuješ za neobjektivní skutečné přednosti deb systému, tak s tím bohužel nic nenadělám.

[Mandarinka]

KDYŽ bude někomu stát za námahu se tím probírat. Kdybych měl místo mozku počítač přímo napjený na internet, docela by mě lákalo probírat se netem a opravovat bláboly, co lidi všude možně potí. Ale protože jsem jenom člověk, tak se na to většinou vykšlu, protože času je málo, abych ho marnil na blbosti.

[Ilfirin]

Tak tak Marku. Tvá minulost je temná a nečistá. Musíš dojít ke svaté řece, v ní se za úplňku vykoupat a pak z tebe teprve budou smyty všechny tvé Gentoo hříchy.

[Käyttäjä 11133]

[paskma]

Že jsou deby pouze pro debian, ano, to jsou. Debian a Ubuntu spolu v tomhle nejsou kompatibilní. Balíčky mezi jednotlivýma release Ubuntu taky ne. Jistě, je to omezení.

Na druhou stranu, klad této "feature" je, že pokud máte deb pro Ubuntu Gusty, tak na U.G. jistojistě funguje.

Pokud mám nainstalovat program, který nemá balíček pro moji distribuci, raději sáhnu po kompilaci ze zdrojů.

Jestli jde vyrobit RPM použitelné pro různé distribuce, tak se obávám, že v praxi je to stejně dost ošemetná záležitost. Já rozhodně neříkám, že je RPM nějak špatné - formát toho balíku je asi ekvivalentní DEBům. Ale prostě DEBy mi vždy fungovaly velmi spolehlivě, s RPM jsem experimentoval před lety (ne moc úspěšně a asi to bylo mou vinou) a předpokládám, že rozcházení "cizího" balíku může být pěkně o hubu.

[extender]

Na druhou stranu, klad této "feature" je, že pokud máte deb pro Ubuntu Gusty, tak na U.G. jistojistě funguje.

ROFL. To je snad samozřejmost, nikoli klad?

[Ondrej 'SanTiago' Zajicek]

To je samozrejmost pouze v pripade, ze balicky se pouzivaj pouze v ramci jedne distribuce. Pokud bys predpokladal univerzalni balicky se zavislostmi podle jmen souboru, tak to samozrejmost urcite neni a je tam mnoho duvodu, proc by to nemuselo fungovat.

[Ses]

Že jsou deby pouze pro debian, ano, to jsou. Debian a Ubuntu spolu v tomhle nejsou kompatibilní. Balíčky mezi jednotlivýma release Ubuntu taky ne. Jistě, je to omezení.

Asi mám štěstí, ale občas instaluji balíček z Debianu do Ubuntu a zatím (musím zaklepat) žádný problém...

[belisarivs]

Mne se zase stalo, ze mi v Debianu nesel udelat balicek podle jiz vytvorenych debian/rules. Pry to bylo pro Ubuntu.

[freshmouse]

Balíčky mezi jednotlivýma release Ubuntu taky ne.

Ehm, a není to čistě náhodou kvůli tomu, že v dalším vydání Ubuntu jsou oproti minulému i knihovny a aplikace ve vyšších verzích? A tudíž to nezávisí na balíčcích jako takových, ale na jejich obsahu?

Příklad: zkus si (klidně s RPM) nainstalovat software A, které potřebuje B ve verzi 2, přičemž je dostupné jen B ve verzi 1...

Ach jo.

[alblaho]

Ano, přesně tím to je. Zkrátka vytvořit nějak "univerzální" balíčky je problém, ať pro RPM nebo pro DEB.

[JKK]

Tak problém to je u obou. Ale možnost požadovat knihovnu abc.so verze 3.1 v RPM je IMHO snazší, než zahrnout všechny existující názvy DEB baíčků pro všechny existující Debian-based distra. Výhoda bude v tom, že můžu pžadovat závislost balíčku, který třeba ještě ani nevznikl díky vazbě na konkrétní knihovnu. Takže když se v průběhu času abc.so přesune z balíku A do balíku B, solver by to měl vyřešit. V Debianu, pokud se nepletu, musí přepsat všechny zainteresované balíky!

[CEST]

Ale možnost požadovat knihovnu abc.so verze 3.1 v RPM je IMHO snazší, než zahrnout všechny existující názvy DEB baíčků pro všechny existující Debian-based distra.

No, z mych zkusenosti naopak plyne, ze debian based distra maji jednotny nazvy balicku (nazev, pripadne nazev-verze), dale je znak podtzitko a nasleduje skutecne verze baliku, dal pak nasleduje architektura. Vetsinou tak plati, ze nejakej DEB z nejaky verze debianu jde nainstalovat na jiny debian based distra, zalozeny na ty originalni verzi debianu.

Naopak co jsem delal drive s RH, tak RH, Mandrake i SUSE mely pro jeden stejnej program ruzny jmena (nebo prinejmensim verze), takze neslo vzit balik od SUSE nebo MDK a nainstalovat na RH, protoze to vyzadovalo jinej RPM s nazvem, kterej se v RH jmenoval samozrejme jinak.

[JKK]

No, z mych zkusenosti naopak plyne, ze debian based distra maji jednotny nazvy balicku (nazev, pripadne nazev-verze), dale je znak podtzitko a nasleduje skutecne verze baliku, dal pak nasleduje architektura.

Jednotný mají pouze styl pojenovávani, sttejně jako RPM má jednotný styl pojmenovávání. Přijde mi, že z RPM konvence lze vyčíst o něco více informací. Stačí se podívat na Debian vs. Ubuntu, a je jasné, že kompatibita je děj náhodný, nikoli zamýšlený.

RH, Mandrake i SUSE mely pro jeden stejnej program ruzny jmena (nebo prinejmensim verze)

Tohle právě řeší RPM tím, že odkazuje na soubory. Není tedy třeba znát, ve kterém balíku se v dané distribuci knihovna nachází. Solver si ji najde sám. Proto není vyřešení závislostí mezí různými distry závislé na pojmenování balíčku jako u Debianu.

[Käyttäjä 11133]

Jenže to je právě ono. RPM závisí na konkrétních knihovnách v konkrétních verzích.

[freshmouse]

Ale to je úplně jedno. Jak můžeš provozovat A, pokud potřebuješ B2, ale máš jen B1? Ať už jsi to sám kompiloval, nebo to máš z Deb nebo RPM nebo čehokoli jiného...

[Jirka P]

RPM závisí na konkrétních knihovnách v konkrétních verzích.

... zkompilovaných se správným ABI, správnými volbami a správnými verzemi třetích knihoven?

Tím chci říct, že rozhodně neplatí "stejné jméno souboru => bude to fungovat." Ono to 100% neplatí ani u jmen balíků, ale aspoň se dá říct do bugreportu "reporter: vole, tvůj balik závisí na špatnym balíku" na rozdíl od "packager: z kerý žumpy si vyhrabal tuhle knihovnu?"

Na druhou stranu chápu, že pro enterprise binární distro, který má za cíl podporovat binární aplikace třetích stran, je ten RPM způsob asi vhodnější.

[Käyttäjä 11133]

Ono se samozřejmě předpokládá, že uživatel bude využívat balíčky pro konkrétní distribuci, tak nevím proč tady strkáš ten příklad:

packager: z kerý žumpy si vyhrabal tuhle knihovnu?

protože stejně tak může nastat stejný případ kdy to bude

packager: z kerý žumpy si vyhrabal tenhle balík se stejným jménem?

A anapříklad u kernelu umí záviset na konkrétních symbolech.

mantisha:/home/marek # rpm -qp --requires madwifi-kmp-default-0.9.4_2.6.25.4_9.1-1.i586.rpm
rpmlib(VersionedDependencies) <= 3.0.3-1
kernel-default
grep
coreutils
/bin/sh
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
kernel(default:vmlinux) = e61690aa8c2e0b5e
rpmlib(PayloadIsLzma) <= 4.4.2-1
mantisha:/home/marek # rpm -qp --provides madwifi-kmp-default-0.9.4_2.6.25.4_9.1-1.i586.rpm
madwifi-kmp = 0.9.4_2.6.25.4_9.1
ksym(_ath_hal_attach) = ea10ec7e
ksym(ath_hal_computetxtime) = 770fb583
ksym(ath_hal_detach) = 9616c7c2
ksym(ath_hal_getuptime) = 2d2cd95d
ksym(ath_hal_getwirelessmodes) = 88074857
ksym(ath_hal_init_channels) = e8a4894a
ksym(ath_hal_memcmp) = 93cb6276
ksym(ath_hal_memcpy) = a0fa8bf4
ksym(ath_hal_memzero) = 4dce8c00
ksym(ath_hal_mhz2ieee) = 62f37fda
ksym(ath_hal_printf) = 5b1d4795
ksym(ath_hal_probe) = 51a400eb
ksym(ath_hal_process_noisefloor) = cf91b80d
ksym(ether_sprintf) = d0732629
ksym(ieee80211_aclator_get) = 5caa4f9c
ksym(ieee80211_aclator_register) = ad58224e
ksym(ieee80211_aclator_unregister) = 551ef76e
ksym(ieee80211_add_wds_addr) = 99d437f8
ksym(ieee80211_alloc_node) = 2a62053c
ksym(ieee80211_announce) = 879f53fa
ksym(ieee80211_announce_channels) = 16e54b10
ksym(ieee80211_authenticator_backend_get) = 34b03391
ksym(ieee80211_authenticator_backend_register) = 7f290d29
ksym(ieee80211_authenticator_backend_unregister) = 8ee89cfe
ksym(ieee80211_authenticator_register) = 5021f947
ksym(ieee80211_authenticator_unregister) = 9974adc5
ksym(ieee80211_beacon_alloc) = c716d8f0
ksym(ieee80211_beacon_miss) = be0d8b18
ksym(ieee80211_beacon_update) = 53297b36
ksym(ieee80211_bg_scan) = 1514341e
ksym(ieee80211_chan2ieee) = 3c384c88
ksym(ieee80211_chan2mode) = 5f729065
ksym(ieee80211_cipher_none) = ddb95144
ksym(ieee80211_create_ibss) = d6f7910a
ksym(ieee80211_create_vap) = f7a3a23f
ksym(ieee80211_crypto_attach) = 25643454
ksym(ieee80211_crypto_available) = eef90ede
ksym(ieee80211_crypto_decap) = 2faa52c5
ksym(ieee80211_crypto_delglobalkeys) = ac06045c
ksym(ieee80211_crypto_delkey) = 9771ad25
ksym(ieee80211_crypto_detach) = a914437b
ksym(ieee80211_crypto_encap) = dac0f942
ksym(ieee80211_crypto_newkey) = a06a3b94
ksym(ieee80211_crypto_register) = 6622a37e
ksym(ieee80211_crypto_setkey) = 15eb2422
ksym(ieee80211_crypto_unregister) = ac8e5d86
ksym(ieee80211_crypto_vattach) = 313f1b6c
ksym(ieee80211_crypto_vdetach) = bd4f6c43
ksym(ieee80211_ctl_subtype_name) = f539e971
ksym(ieee80211_del_wds_node) = e1725a6b
ksym(ieee80211_dfs_test_return) = 2bd0ad1b
ksym(ieee80211_dturbo_switch) = ac5ee46d
ksym(ieee80211_dump_pkt) = a9c9b10
ksym(ieee80211_encap) = ddcd18f3
ksym(ieee80211_find_channel) = 5edba707
ksym(ieee80211_find_node) = a09fa133
ksym(ieee80211_find_rxnode) = b05400c3
ksym(ieee80211_find_txnode) = 926cd855
ksym(ieee80211_find_wds_node) = cde219a2
ksym(ieee80211_free_node) = b5680abd
ksym(ieee80211_getcfframe) = 242a6041
ksym(ieee80211_getrssi) = b0918563
ksym(ieee80211_ibss_merge) = eadeb4b8
ksym(ieee80211_ieee2mhz) = 54982107
ksym(ieee80211_ifattach) = abdbc710
ksym(ieee80211_ifdetach) = 5f350154
ksym(ieee80211_input) = f3599314
ksym(ieee80211_input_all) = 7f7dd4da
ksym(ieee80211_input_monitor) = a0edd37a
ksym(ieee80211_ioctl_create_vap) = f6376fc7
ksym(ieee80211_iterate_dev_nodes) = 4b02dcda
ksym(ieee80211_iterate_nodes) = 714f2261
ksym(ieee80211_mark_dfs) = 6520e4ae
ksym(ieee80211_media2rate) = 469b25e9
ksym(ieee80211_media_change) = 8b62080f
ksym(ieee80211_media_status) = 6fa206ab
ksym(ieee80211_mgt_subtype_name) = 737a25a1
ksym(ieee80211_mhz2ieee) = 80b53b09
ksym(ieee80211_monitor_encap) = 2ff3c8f9
ksym(ieee80211_node_authorize) = fb29da0
ksym(ieee80211_node_leave) = d0188136
ksym(ieee80211_node_unauthorize) = 4997620e
ksym(ieee80211_note) = 2ec0a37d
ksym(ieee80211_note_frame) = b021eb3b
ksym(ieee80211_note_mac) = 588c59ad
ksym(ieee80211_notify_michael_failure) = 9535eba7
ksym(ieee80211_notify_replay_failure) = f4199f18
ksym(ieee80211_phymode_name) = aa7782e
ksym(ieee80211_print_essid) = 3075477
ksym(ieee80211_proc_vcreate) = 44a890b9
ksym(ieee80211_rate2media) = 1cbe2d47
ksym(ieee80211_rate_attach) = 3a3e38f0
ksym(ieee80211_rate_detach) = 42ddc169
ksym(ieee80211_rate_register) = 57470585
ksym(ieee80211_rate_unregister) = d6c0376a
ksym(ieee80211_remove_wds_addr) = be9b5ba5
ksym(ieee80211_saveie) = 2c1b6439
ksym(ieee80211_scan_dfs_action) = 6c4a6987
ksym(ieee80211_scan_dump_channels) = 98e463da
ksym(ieee80211_scanner_get) = 4ee6889b
ksym(ieee80211_scanner_register) = 7a05a549
ksym(ieee80211_scanner_unregister) = fec38de5
ksym(ieee80211_scanner_unregister_all) = 87c420a
ksym(ieee80211_send_qosnulldata) = 68b90721
ksym(ieee80211_setmode) = b8ec8e7f
ksym(ieee80211_sta_join) = 82e9cea9
ksym(ieee80211_sta_join1_tasklet) = 1ed27f27
ksym(ieee80211_start_running) = 40acaed4
ksym(ieee80211_start_scan) = 7e061072
ksym(ieee80211_state_name) = bc0d2992
ksym(ieee80211_stop) = e5b64cec
ksym(ieee80211_stop_running) = 81b49b14
ksym(ieee80211_vap_attach) = 4303db0a
ksym(ieee80211_vap_detach) = ed7be7fb
ksym(ieee80211_vap_setup) = c0623fc0
ksym(ieee80211_wme_acnames) = 1009d14d
ksym(ifmedia_ioctl) = 200660f1
madwifi-kmp-default = 0.9.4_2.6.25.4_9.1-1
mantisha:/home/marek #  

Ale máš pravdu, kdyby umělo záviset na konkrétních symbolech u všech knihoven bylo by to cool, ale afaik to neumí. Zkusím to někdy někde navrhnout

[Jirka P]

Ono se samozřejmě předpokládá, že uživatel bude využívat balíčky pro konkrétní distribuci, tak nevím proč tady strkáš ten příklad

Protože ostatní v diskuzi právě tohle (možnost použít mimo distribuci) vyzdvihují jako velkou výhodu. Pokud distribuce má fungovat především jako celek (já si to taky myslím), tak závislost na konkrétním balíku nikoho nezabije. Kde je víc balíků poskytujících stejnou knihovnu se stejnou sémantikou/ABI/..., tam se dají použít virtuální balíky (v Debianu je tuším tahle situace u libGL.so). Naopak, kde jsou dva balíky se stejnou knihovnou s různou sémantikou/ABI/..., tam má uživatel smůlu, ale aspoň si nenainstaluje něco, co pak nefachá.

Ale máš pravdu, kdyby umělo záviset na konkrétních symbolech u všech knihoven bylo by to cool

Nevím, jestli by to stačilo.

[MJ]

Ale máš pravdu, kdyby umělo záviset na konkrétních symbolech u všech knihoven bylo by to cool, ale afaik to neumí. Zkusím to někdy někde navrhnout

Bohužel nestačilo: dvě různé verze knihovny mohou mít funkci stejného jména, která se volá jinak. Typický příklad je třeba, má-li funkce za parametr pointer na strukturu, která mezi verzemi změnila deklaraci.

[depka]

A anapříklad u kernelu umí záviset na konkrétních symbolech.

k cemu to je? to se mi s jednim balikem bude instalovat nove jadro?

[Käyttäjä 11133]

Třeba k tomu, že symboly nemusí poskytovat jenom samotné jádro, ale taky balík obsahující jaderné moduly. Máme balík A-kmp a balíl B-kmp. B-kmp závisí na symbolech, které poskytuje balík A-kmp a ne jádro. Pak ještě existuje balík C-kmp, který poskytuje stejné symboly jako A-kmp. Solver může vybrat kterýkoli z těchto.

[happy barney]

inak povedané, virtuálny balík ...

[David Šmíd]

Nic jsi nepochopil, Ivánku...

---

[JKK]

Virtuální balík si vybere z 10 alternativ?

[MJ]

Balík ne, ale solver si vybere libovolný z 10 balíků, které ten virtuální poskytují.

[Kyosuke]

Ale k tomu snad není zapotřebí virtuální balík? Zyppí solver pracuje hlavně s capabilities a pokud instaluju B-kmp, vybere takovou kombinaci ostatních balíků, která splní všechny požadované capabilities (pokud je to možné, třeba hardware capabilities si z prstu vycucat nemůže ). Potřeba "prázdného kontejneru na fíčuru" mi tady uniká. Pokud řešení existuje více, tak nějaké upřednostní na základě kritérií, které si z hlavy nevybavím (ale kupříkladu taková potřeba změny architektury některých stávajících balíků určitě odkopne řešení hodně dozadu, dokonce myslím, že taková instalace vyžaduje interaktivní potvrzení).

[MJ]

Problém je hlavně v rozporu mezi syntaxí a sémantikou. RPMkové capabilities (tak, jak je chápu já) jsou čistě syntaktická záležitost: odkazují se na jména souborů a jiných objektů. Ostatní balíčky ovšem obvykle závisí na sémantice těchto objektů a nikdo nezaručuje, že shoda jmen implikuje shodu sémantiky.

[David Šmíd]

Špatně. "RPM capabilities" to je čistá sémantika. Balíček si sám určuje, které "provides" a v jaké verzi poskytuje. Výjimkou jsou pouze "file provides" (neverzovaná jména souborů v něm obsažená) a verzované názvy knihoven automaticky přidávané mezi "provides" při vytváření balíčku.

---

[MJ]

Neříkám, že nemohou existovat capability, které jsou sémantické. Ovšem ty, které tu byly vyzdvihovány jako přednost RPM, totiž jména souborů apod., jsou čistě syntaktické.

[CEST]

Na fóru sem nalezl velmi častý dotaz proč ještě někdo používá to zaostalé RPM, když balíčky Debianu a Gentoo jsou mnohem lepší.

Nebylo to spis mysleno tak, ze SPEC file je "takovej divnej", kdezto debiani control (txt file) a rules (make file) a Gentoovskej ebuild (bash) jsou jednodussi na uceni?

kdyz jsem jeste v dobe RH7.3 az RH9 zkousel delat SPEC soubory, tak to bylo obcas docela drina. Tehdy to melo jakousy %if konstrukci, ale nic moc slavnyho. Samozrejme v tomhle ma ebuild s USE hodne navrch.

[Käyttäjä 11133]

Ehm.. Spec je jen makrojazyk nad bashem :-p Můžeš tam používat konstrukce z bashe.

[zde]

Mě na RPM vadí už to, že poměrně dlouhou dobu šlo o proprietární closed source formát. Pak ho sice otevřeli, ale pro výstrahu to stejně doporučuju ignorovat do konce světa .-)

[extender]

aplikujete to na veškerý SW, který měl z počátku jinou než GPL licenci?

[zde]

Bohužel jen tam kde mám alternativu..

[JKK]

takže zcela jistě nepoužíváte žádný program s Qt toolkitem?

[bibri]

Link by nebyl? Docela by mně to zajímalo, nedovedu si příliš dobře představit proprietární formát s otevřenými zdrojáky...

[pc2005]

<nonflame > A stejně nejlepší jsou balíčky slacku . </nonflame >

[Honza "tux" Friesse]

Pššt, nebo se tady zase vyrojí spousta lidí s "ftipnými ftipy" typu "Jak udělat z RPM distribuce Slackware? alias rpm='rpm --nodeps'".

[Kyosuke]

To spíš balíčky z Arche. Ale skoro mi přijde, že cokoli složitějšího je už záležitost pro nadnárodní iniciativy typu SUSE či Debian, kdežto formát archího balíčku bych díky jeho jednoduchosti ještě dokázal vymyslet sám.

[pc2005]

V jednoduchosti je síla. Skvělé je, že do takovéhoto formátu jde krásně přidávat další funkce.

[bibri]

Autor mi mluví z duše, snažím se již měsíc zkrotit distro na deb balíččích (Ubuntu HH) a mám toho akorát tak po krk. Klidně uznám, že polovina problémů je způsobena mou neznalostí a jiným zvykům při práci, ale na druhou stranu třeba říci, že man apt-get jsem četl již několikrát. Co mně vytáčí?

Synaptic jako GUI je neuvěřitelný user unfriendly bazmek. Kromě toho, že má chyby v GUI (špatně scolluje, tlačítko hledat musím hledat napopáté než zaktivní) tak mu některé možnosti RPMdrake (mám v Mandrivě) chybí. Třeba hledat soubor v nenainstalovaných balíčcích - moc faj věc když hledám nástroj, ale neznám jméno balíku. Jo kdyby to neuměl jen on, tak prosím, ale neumí to ani apt-get. A o krásném nástroji apt-file se v jeho manu nedočtete, to vám musí poradit kamarád - dlouholetý debianista.

Vadí mi schizofrenie uživatelů debu. Dpkg používají jen masochisté, přesto když něco nejde těmi lepšími, přiletí sprcha ve formě pkg-query -W -f='${Installed-Size;10}t${Package}\n' | sort -k1,1n. Bomba. Apt-get je zastaralý a neměl by se používat - raději používejte nový aptitude. Přesto jsou všechny skripty a návody psány pro něj, stačí se podívat třeba na Ubuntu wiki. Pomlčím o zjištění, že se ty dva nástroje nechovají stejně a mohou při stejném zadání dávat různé výsledky - což se ale od chytráků v diskusích nedozvíte. Prase aby se v tom vyznalo...

Krásné stavy deb balíčků (nainstalován, ale nezkonfigurován, nainstalován a zkonfigurován atd...) jsou čirá onanie. Balík buď potřebuju, nebo ne, podle toho je nainstalován nebo není. Když potřebuju soft zkonfigurovat, mám na to nějaký nástroj nebo to umím ručně. A udělám si to tehdy, až to potřebuju, ne při instalaci. Naopak bych ve skriptech ocenil možnost jednoduše ten konfigurační nesmysl, co se sám spouští, vypnout. Parametr --assume-yes nezabírá a jediné, co jsem našel (a to ještě ne já), je DEBIAN_FRONTEND=noninteractive + DEBIAN_PRIORITY=critical. Bomba.

A vůbec, je to moc fajn věc taková konfigurace - proč se to ale plete k balíčkům? Nemá to tam vůbec co dělat - je volbou každého člověka, čím si daný soft nakonfiguruje. Že na to v Debianu nejsou klikátka je problém Debianu, já je v distribuci mám a fungují dobře. Nechápu také výběr balíčků, ke kterým se tahle krása spouští, téměř v každém balíčku je nějaký nastavitelný software, přesto se to spouští jen někdy a zdaleka ne všechny balíčky tohle podporují. Zase schizofrenie? Proč se umí balíčky rekonfigurovat, ale takovou základní věc, jako vyhledávání souboru v nenainstalovaných balících obstarává nějaká další externí toolsa, která ani není v základním systému nainstalována? Co to je?

Moc hrubé zamykání, to je taky paráda. Spuštěný Synaptic zablokuje jakýkoliv apt-get - fuj! Tohle se mi v Mandrivě nestává - urpmi mohu používat i když mi RPMDrake běží a prohlížím si dva balíčky. Stejně tak se mohu dotazovat na balíčky i když běží instalace na jiné konzoli. A proč taky ne? Neví snad autoři Synapticu, co je to read-only přístup?

V žaludku mi leží i formátování výstupu - nevím, kdo ty toolsy psal, ale zřejmě měl dost času na čtení. Já ho nemám, nepotřebuju při instalaci balíku vědět, kolik mám na disku souborů a že můj balíkovač právě čte databázi. To mám dost na háku. Potřebuju vědět, co všechno se nainstaluje, odkud, kolik toho je a kdy to bude. Nic víc a nic méně. Kdo neví, o čem mluvím, ať porovná výpisy apt-get a urpmi.

Pozor - nikde netvrdím, že deb či jeho nástroje jsou výrazně horší než u RPM. Ty mají taky svoje mouchy. Pouze reaguji na nesmyslná tvrzení fanatických zastánců debu, kteří píší, jak je RPM na houby, protože oni s ním měli potíže a že veškeré RPM-based distribuce jsou tudíž na nic (taky časté). Přitom si nevidí ani na špičku nosu - bože můj, kdyby kvalita distra závisela na použitém balíčkovacím systému, kde bychom byli?

Jenže to není jen o apt-get, urpmi, yumu nebo dpkg. Je to třeba i o kvalitně udělaných balíčcích a dalších okolnostech. "Debian umí přechod na novou verzi jen pomocí apt-get i po čtyřech letech" - jo, jo, i v Mandrivě je možný přechod ob dvě verze distra pouze s uprmi, i když to není nic moc (jedna verze je v klidu). Problém může být třeba v tom, že dvě verze Mandrivy jsou rok, dvě verze Debianu čtyři roky. Když to ale vezmeme jen podle druhého měřítka, vypadá to blbě, ale blbé to není. Vždy je třeba srovnávat srovnatelné. Taky to může být o tom, že daný uživatel byl v době používání RPM linuxové tele - viděl jsem takových telat spoustu a dost dlouho jim trvá poznání, že chyba může být i v nich, ne v rpm.

Takže po všech těch siláckých kecech o debu a apt-get, které všude čtu, je to pro mne celkem velké zklamání. Je to nástroj ekvivalentní tomu, co znám, nic víc s nim dělat nejde. Možná umí navíc věci, které nepotřebuju, ale nepřišel jsem na ně. Vadí mi roztříštěnost a přitom nedotaženost základních nástrojů, či jejich nepřítomnost v instalaci (celou dobu mluvím o Ubuntu HH). No, abych jen nenadával, občas jsem se pobavil, tak se pobavte taky :D.

Od teď považuji jakýkoliv flame o tom, že deb je lepší než rpm a apt-get je lepší jež (urpmi, yum, ...) za lež do nebe volající. Dříve jsem se neúčastnil pouze proto, že nerad diskutuji o věcech, které nemám vyzkoušené. Teď už je ale vyzkoušené mám s výše uvedeným výsledkem. Každého dalšího - s prominutím - debila, který bude demagogicky argumentovat na téma lepší deb, pošlu sem, ať si počte, když už to dalo takovou práci.

Howgh.

[David Jaša]

Ony hlavní výhody debu byly/jsou tyto:

1) slabé závislosti (Suggests: a Recommends:)

2) metabalíčky, alternativy (prázdný balíček totem s Depends: totem-gstreamer | totem-xine)

3) virtuální balíky (všechny balíčky, které umí posílat maily mají: Provides: mail-transport-agent)

4) množství balíčků přímo v distribuci

5) frontendy nad dpkg (dselect/apt-get/aptitude)

V jednotlivostech RPM deb dohání a předhání, ale Debian toto všechno měl pohromadě a funkční už v době, kdy se v RPM-based distribucích používalo tak akorát rpm -i balíček.rpm.

Jinak díky za pohled zvenku na dpkg/apt.

[Käyttäjä 11133]

1) slabé závislosti (Suggests: a Recommends:)

RPM je umí taky, minimálně to susí.

3) virtuální balíky (všechny balíčky, které umí posílat maily mají: Provides: mail-transport-agent)

Tohle jde v RPM taky.

4) množství balíčků přímo v distribuci

To má být výhoda formátu balíčků? Ale notak...

5) frontendy nad dpkg (dselect/apt-get/aptitude)

Zypper?

[David Jaša]

A tu větu pod seznamem sis přečetl? Klíč je, že v Debianu toto všechno fungovalo už "kdysi dávno", rpm-based distribuce se tyto věci "učí" až v poslední době (např. Mandriva až ve verzi 2008.0).

4) množství balíčků přímo v distribuci

To má být výhoda formátu balíčků? Ale notak...

Jasně, není to vlastnost balíčkovacího systému. Spíš okolnost, kvůli které byly ty vlastnosti/výhody v Debianu dostupné mnohem dřív než jinde.

[bibri]

1 - nevím, jak jsem již psal;

2 - task balíček se objevil v MDV 2006 na konci roku 2005, nesmíte věřit jen marketingu, stačí se podívat na FTP - dobrá věc, ale dalo se bez ní žít celkem v klidu;

3 - dělá IMHO Mandriva od nepaměti a IMHO i jiná rpm-based distra,

4 - mám všechno, co potřebuji, už dlouho a víc mne nemusí zajímat;

5 -první frontend na urpmi jsem viděl snad ve verzi 8.1 v roce 2001 a byl stejně špatný jako Synaptic nyní.

IMHO kromě 1 nic z toho nezávisí na deb/rpm, ale na tvůrci distribuce či jiných lidech. Stejně jako u mně je největší problém všech těch argumentů nikoliv v nedokonalosti popisovaných prostředků, ale v neznalosti pisatelů (nic osobního, prostě je to tak).

Stačí si uvědomit, že oba ty formáty se vyvíjely vedle sebe a čas od času jeden od druhého kopírovaly. IMHO jsou adekvátní a nabízejí stejné možnosti. Použití deb/rpm ani nástrojů nad nimi nemá žádný vliv na kvalitu distra, to je nesmysl. Argumenty typu "rpm dependency hell", který jsem u rpm viděl naposledy v roce 2000 před přechodem na Mandrivu (na fórech je vidím i o osm let později), také - a zbytek ať si přebere každý sám...

[David Jaša]

Jasně. Mě šlo o to, že Debian musel vzhledem ke své rozsáhlosti některé aspekty řešit dřív než RPM distra a z té doby jsou taky mýty o tom jak .deb rulezzz a .rpm suxxx. Ještě krátce ke 4 a 5:

4) vám stačí to, co je přímo v distribuci ale Marek by třeba ocenil program X a já program Y, které už tam nejsou. Debian to řeší tím, že obsahuje všechno, co je někdo ochoten udržovat, Ubuntu repozitáři universe a muliverse s omezenou podporou, RPM distra obecně externími repozitáři a SUSE také uživatelskými repozitáři v rámci OBS, Gentoo overlayi a Arch AURem. Už jejich existence znamená, že po dalších a dalších balíčcích poptávka je.

5) GUI k aptu dlouho nikdo nechtěl, to až po nástupu Ubuntu, které ale dává síly jinam... I když já používám primárně aptitude, tak mě to osobně moc netrápí.

[bibri]

Rozjíždí se nám rozumná diskuse i s argumenty - výborně, užijme si ji, než přiletí fanatici....

Osobně mýtus považuji i tu (historickou) rozsáhlost Debianu a z ní plynoucí aspekty a to všechno dále. Podíval jsem se na starý Mandrake 8.2 a v oficiálních repozitářích jsem našel cca 3300 balíčků o objemu 2,4GB. Plná instalace mohla mít čtyři CD, kolik měl tehdy (2002) Debian - sedm? A balíčků, šest tisíc? To není rozdíl ani v řádech... IMHO nelze ani náhodou na základě toho tvrdit něco o rozsáhlosti distra a z toho plynoucí technické dokonalosti debu. Takže opět jen neznalost některých uživatelů? Nebo se mýlím?

4 - nenapsal jsem, že mi stačí, co je v distribuci, ale že mám, co potřebuji, a to jsem velmi náročný uživatel. Kromě oficiálních repo používám ještě repo PLF a vlastní malé repo :). I v Mandrivě platí, že obsahuje všechno, co je někdo ochoten udržovat - Contrib má od nepaměti a přesně k tomu je určen. Rozdíl je pouze v silnějších vstupních podmínkách - Mandriva si už nedovolí mít tam licenčně závadné věci (kdysi ano), proto máme PLF. Hodně PLF balíčků je shodných s tím, co je v Main/Contrib, jen se kompilují s jiným flagem a proto obsahují navíc podporu toho, či onoho. Spousta lidí (např já) má vlastní repo už proto, že by nevyhověla ani licenčním ani kvalitativním podmínkám Contribu. Nic víc, nic méně.

Každopádně ani z existence externích repozitářů neplyne nic, maximálně tak to, že se mnou uváděný počet balíčků na začátku článku (Mandrake 8.2) by mohl být ještě vyšší, přesto to ty nástroje dávaly a nepamatuji si nějaké extrémní potíže. Spíš mně to jen utvrdilo v domnění, že i ta rozsáhlost Debianu a z toho vyplývající kvalita debu je jen další mýtus.

Spíš se mi motá v paměti nějaký starý příběh o tom, jak byl kdysi deb celkem k ničemu a v momentě, kdy přišel lepší rpm, tak se vývojáři vzchopili, a pořádně ho předělali (s patřičnou inspirací). Situace se obrátila, rpm ho pak musel dohánět (opět s inspirací, že) atd. To by mohla být pro podobnou historku dobrá živná půda, bohužel si nepamatuji, kde a kdy jsem to četl. Možná někdo doplní odkaz nebo další informace.

[Aleš Kapica]

Rozumná diskuze? Rozum je zalezlý někde v koutě a tiše pláče od chvíle co byl publikován tenhle blogpost, protože jeho autor prostě nepochopil, že to co vyhovuje jednomu, nemusí vyhovovat druhému a do pekla závislostí se lze dostat jak u RPM tak u DEB. Pro mne byl rozdíl v tom, že u rpm jsem skončil na tom, že něco se nainstalovalo a něco ne. Pak už jsem se točil na místě a nemohl to ani doinstalovat, ani vrátit. Apt mi nikdy nedovolil nainstalovat něco co by znamenalo nabourání systému, a byl také schopen ošetřit při instalaci správné pořadí balíků.

[bibri]

Rozumná diskuze? Rozum je zalezlý někde v koutě a tiše pláče od chvíle co byl publikován tenhle blogpost, protože jeho autor prostě nepochopil, že to co vyhovuje jednomu, nemusí vyhovovat druhému a do pekla závislostí se lze dostat jak u RPM tak u DEB.

Můžeš to zlepšit - já to jen uvítám a ostatní určitě také.

Pro mne byl rozdíl v tom, že u rpm jsem skončil na tom, že něco se nainstalovalo a něco ne. Pak už jsem se točil na místě a nemohl to ani doinstalovat, ani vrátit.

To nic neříká o kvalitách debu ani rpm a o tom ta diskuse je.

A pozor - neříká to nic ani o tom, že by rpm neuměl to, co píšeš. Já umím s rpm vrátit všechno, co provedl. Stejně tak umím doinstalovat něco, co nechce. Nepoužívám to, resp. nepoužil jsem to už dlouho, ale to neznamená, že by to neuměl. Umí to dlouho, že to neumíš ty není problém rpm (ani balíčků ani nástrojů, trochu se nám to tu míchá).

Apt mi nikdy nedovolil nainstalovat něco co by znamenalo nabourání systému, a byl také schopen ošetřit při instalaci správné pořadí balíků.

To ještě neznamená, že je neomylný, pořádně si přečti toto - nechápu, jak k tomu může dojít. Přesto k tomu došlo. Co to dokazuje? Nic!

BTW můj první kontakt s balíčkovacímy systémy byl právě dpkg. Utekl jsem od něj k rpm :).

[Aleš Kapica]

Jednoduché. Apt tím jasně naznačil, že ty jazykové balíky jsou pro jinou verzi OpenOffice než která je v repository k dispozici. Pokud trváš na tom, že tento balík chceš mít v systému i za cenu že ti samotné OpenOffice odinstaluje, tak můžeš pokračovat.

Jinak v dobách kdy jsem pracoval s Madrake to co apt nadstavby pro rpm neuměly ale nikde netvrdím, že to neumí dodnes. Ve skutečnosti je úplně jedno jestli je balík rpm nebo deb - proto považuji celý tenhle blogpost za nesmyslný, protože o tom zda instalace dopadne úspěšně nebo neúspěšně VŽDY rozhoduje to jak je balík udělaný. Už jsem několikrát zmínil, že Debian používám proto, že je roll-on distribuce, ne proto že používá zrovna deb balíky.

Mandrake jsem používal do té doby než se přejmenoval na Mandrivu (ke spojení s Conectivou došlo v dubnu r.2005). Synaptic jsem lokalizoval v listopadu 2003 jako nadstavbu pro apt4rpm. A v září 2004 jsme spolu my dva vyměnili pár mailů a zrovna v jednom z nich jsem zmiňoval, proč mi urpmi nevyhovuje tolik jako apt. Dost dobře jsem nechápal, proč se upřednostňoval vývoj nového specifického nástroje pro správu balíků, když byl k dispozici nástroj, který by umožnil sjednotit správu balíků napříč distribucemi. Co rpm distro, to jiný nástroj. Zajímavé je, že tím kdo přišel s apt4rpm byla právě Conectiva.

Už je to dlouho co Mandrivu nepoužívám, takže neznám její dnešní nástroje pro správu balíků, proto se s nikým nepřu o tom, co je lepší. Ale irituje mě když někdo nadává na balíčkovací systém kterému nerozumí.

[extender]

přitom Apt4rpm je nejpomalejší alternativa pro RPM co existuje

[bibri]

Jednoduché. Apt tím jasně naznačil, že ty jazykové balíky jsou pro jinou verzi OpenOffice než která je v repository k dispozici. Pokud trváš na tom, že tento balík chceš mít v systému i za cenu že ti samotné OpenOffice odinstaluje, tak můžeš pokračovat.

Omyl - jak se později ukázalo, byly pro stejnou verzi OO.org. Ověřoval jsem to v přímo v repozitářích na FTP. Kdyby to tak nebylo, nedával bych to sem. Do toho stavu jsem došel pouhým používáním apt-get - potřeboval jsem to distro trochu ořezat, apt-get jsem nechával pracovat v default režimu. Jestli za to můžou balíčky nebo apt-get, netuším, ale stát by se to nemělo a přišlo mi to dost komické.

Dost dobře jsem nechápal, proč se upřednostňoval vývoj nového specifického nástroje pro správu balíků, když byl k dispozici nástroj, který by umožnil sjednotit správu balíků napříč distribucemi. Co rpm distro, to jiný nástroj. Zajímavé je, že tím kdo přišel s apt4rpm byla právě Conectiva.

Já to také nechápal - urpmi přišlo IMHO první, přesto měli ostatní tyto tendence.

Už je to dlouho co Mandrivu nepoužívám, takže neznám její dnešní nástroje pro správu balíků, proto se s nikým nepřu o tom, co je lepší. Ale irituje mě když někdo nadává na balíčkovací systém kterému nerozumí.

Řekl bych, že za tu dobu co s tím musím dělat, jsem se toho naučil docela dost. Nejsem si vědom toho, že by moje výtky byly mimo či byly způsobeny tím, že to neumím používat. Problémy jsem ostatně vždy nějak vyřešil - proto konstatuji, že nástroje jsou adekvátní. To, co jsem popsal jsou zkušenosti (snad) pokročilého uživatele a reakce na nesmyslné flamewary deb vs. rpm. Všechno jsem to tam napsal - stačí pozorně číst a nehledat za tím nic jiného.

[Jirka P.]

Apt tím jasně naznačil, že ty jazykové balíky jsou pro jinou verzi OpenOffice než která je v repository k dispozici

Oprava: ... než kterou má bibri nainstalovanou.

Omyl

Silně pochybuji.

Ověřoval jsem to v přímo v repozitářích na FTP

Spíš myslím, že jste si ověřil něco jiného, než v čem byl problém (kromě toho, že rozhodnutí APTu na FTP nezávisí). Pokud myslíte, že ne, hoďte do placu verze nainstalovaných OOo balíků a verzi instalačních kandidátů.

Jinak můžu poradit jen používat aptitude (kde by se toto nestalo) nebo napsat bugreport na ooo-l10n-cs, protože tahle praxe (deklarování verzované závislosti pomocí Conflicts:) je podle mě porušení debian policy (konflikt mezi balíky neposkytujícími stejnou/podobnou funkcionalitu). Jsou pro to důvody, i když dle mě značně pomýlené. Jenže občas se na debian-devel objeví nějaký exot, který toto prosazuje, a pak je z toho flame, takže bych to nehrotil.

[bibri]

Spíš myslím, že jste si ověřil něco jiného, než v čem byl problém (kromě toho, že rozhodnutí APTu na FTP nezávisí). Pokud myslíte, že ne, hoďte do placu verze nainstalovaných OOo balíků a verzi instalačních kandidátů.

Hardy Heron, povoleny pouze oficialni zdroje (main, multiverse, universe, restricted) a z aktualizaci jen security a updates (provedeno). Nic jineho, zadne externi balicky ani dalsi zdroje... V tech zdrojich je jen jedna sada OOo, to jsem overoval.

Verze baliku bych rad dodal, kdyby je apt-get vypisoval - viz jedna z mych vytek. Mam jen toto a ta virtualni masina je davno v tahu. Je pravda, ze jsem s tim delal psi kusy, ale tohle by se proste stat nemelo. Jak jsem uz ale psal, nic to nerika o kvalite debu, mohou to byt nejake pokopane zavislosti, coz je mnohem castejsi potiz.

[Jirka P]

Hardy Heron, povoleny pouze oficialni zdroje (main, multiverse, universe, restricted) a z aktualizaci jen security a updates (provedeno)

Ubuntu vůbec neznám, ale nemohlo se čirou náhodou stát, že jeden den bylo v těhle zdrojích OOo (např.) 2.3.0 a další den 2.3.1?

ale tohle by se proste stat nemelo

Právě proto by to chtělo ten bugreport.

[anicka]

Můžeš to zlepšit - já to jen uvítám a ostatní určitě také.

To je dost odvážné tvrzení :-P

Máme u nás v susím balíkářském týmu spoustu nápadů na vylepšení RPM, Michal Marek už AFAIK nějaké patche i napsal, ostatní klidně napíšeme na požádání... jen by je od nás musel někdo chtít. Vývoj RPM 4 je zatraceně konzervativní a donutit upstream k přijetí jakéhokoliv patche se skoro rovná nemožnému (už jsem o tom trochu psala níž). RPM 5 je zatím jen pro srandu králíkům. Tak jak ty bugy spravit?

Já možná jen nevím o čem mluvím, do RPM vidím daleko líp než do debianího balíkování, ale naivně se domnívám, že minimálně jednu výhodu debianí balíčky mají: Pokud je tam něco rozbité, dá se to spravit. U RPM to nejde. Nebo jde, ale jen za cenu udržování desítek patchů, což je na pendrek. Já ostatně každou poradu pořád přemlouvám a přemlouvám, abychom to RPM už doopravdy forkli...

Aleš sice podle všeho rozumí RPM jako já debům, ale kdyby potkal opravdový bug, asi ho nespraví... stejně jako nikdo jiný. To je mimochodem IMHO ten úplně největší prů*** u RPM...

[Michal Čihař]

Ano Debianí balíčkování má třeba tu výhodu, že se vyvíjí ... třeba během letoška vznikly asi tři nové formáty zdrojových balíčků, no není to skvělé?

Jinak se naprosto úmyslně do tohoto flamewaru raději nezapojuju, protože znám obojí dost detailně .

[anicka]

Jinak se naprosto úmyslně do tohoto flamewaru raději nezapojuju, protože znám obojí dost detailně .

Chudáku Já mám pořád iluze o tom, že existuje něco, co aspoň trochu funguje. Vědět, jak je to doopravdy (a ono je to jasné - vždycky je to všude stejné) musí být značně frustrující

Já zatím naštěstí můžu zůstat u debianovského idealismu, protože to nepotřebuju umět doopravdy

[Michal Čihař]

Chudáku Já mám pořád iluze o tom, že existuje něco, co aspoň trochu funguje. Vědět, jak je to doopravdy (a ono je to jasné - vždycky je to všude stejné) musí být značně frustrující

Zas tak moc mě litovat nemusíš . No prostě každé má nějaké výhody a nějaké nevýhody. I když dpkg se poslední dobou aspoň trochu hýbe a některé chybějící věci už umí (třeba triggery), nové zdrojové formáty taky určitě jsou pozitivní, ale nemuselo by jich být tolik . Jak je na tom vývoj rpm po ohlášení RPM v5 moc nesleduju.

[bibri]

To je dost odvážné tvrzení :-P

Řeč byla o kvalitě a zlepšení debaty, nikoliv rpm :).

Dík za info zevnitř - myslel jsem, že rpm 5 je v mnohem lepším a pokročilejším stavu. Forku se vyhněte, jak to jen půjde, to je ta nejhorší, nejnákladnější a taky nejdelší možnost ze všech - někdy bohužel jediná :(.

[Käyttäjä 11133]

Ona se alespoň jedna velká distribuce rozhodla přejít na rpm5?

[extender]

... blogpost, protože jeho autor prostě nepochopil, že to co vyhovuje jednomu, nemusí vyhovovat druhému a do pekla závislostí se lze dostat jak u RPM tak u DEB...

Já bych vás prosil, aby jste přestal takto lhát. Nikde netvrdím, že RPM je lepší ani že musí vyhovovat každému.

[Aleš Kapica]

Opatrně s tím obviňováním ze lži. Já také nikde nepíšu o tom, že byste to tvrdil.

[extender]

Zde minimálně naznačujete, né-li tvrdíte, že z mého pohledu je RPM lepší než DEB. To je naprostá lež, protože já hovořím pouze o přenositelnosti a vstřícnosti k jiným distribucím.

Tvzení o tom, že jsem nepochopil, že každému vyhovuje něco jiného jsem vám doložil v předchozím příspěvku.

[David Jaša]

Tady bych to už ukončil, protože jsem Mandrivu nikdy na pevném disku neměl a k linuxu jsem přišel v době, kdy pro RH/Fedoru a SUSE nic takového nebylo a Debian už to měl.

[bibri]

Je to možné, urpmi se v MDV objevilo v roce 2000 a o rok později to byl hlavní důvod, proč jsem utekl od RH k MDV.

[anicka]

Marku, obecne k tomu Tvemu "tohle jde v RPM taky" - problem je v tom, ze susi RPM, na ktere jsi zvykly, neni "to" RPM, i kdyz se tak snazime tvarit. Susi RPM melo oproti upstreamu jeste donedavna vic nez 100 patchu. Ted se sice konecne zacina darit spoluprace a je to lepsi (donedavna nas upstream ignoroval), ale porad je to takovy bes, ze si nekdo na update RPM u nas troufnul naposledy v roce 2005, pokud vim.

Takze uvazovat o prednostech RPM se znalosti jen toho naseho je k nicemu. Vyrobit jakykoliv slozitejsi balik tak, aby rozumne fungoval u nas s nasi furou patchu a treba na Fedore s jejich zcela jinym RPM je docela veda. Susi a fedori balikari o tom, jak to aspon trochu sjednotit, vesele diskutuji uz rok (schyluje se k zalozeni verejneho mailing listu) a zatim jsme se nikam nedostali. Velmi strucny soupis rozdilu v tom, jak balime, je treba tady - Standa Brabec by toho ale mohl vysypat z rukavu nesrovnatelne vic.

Tim vsim jsem chtela naznacit, ze divat se na RPM na neco univerzalniho jakz takz fungujiciho napric distribucemi je dost osidne - co distro, to RPM. (Nevim ale vubec, jak to dela treba takova Mandriva...) Distribuce pouzivajici RPM v tom ale fakt oproti tem debovskym nemaji zadnou velkou vyhodu...

A pokud vim, zrovna ty tagy Suggests a spol. RPM umi jenom tise ignorovat, zbytek se resi jinde

[Käyttäjä 11133]

problem je v tom, ze susi RPM, na ktere jsi zvykly, neni "to" RPM, i kdyz se tak snazime tvarit.

No jasně, to vím. Většinou to doplňuji komentářem "alespoň v SUSE", ale pokud jsem to někde zapoměl, tak se omlouvám.

Susi RPM melo oproti upstreamu jeste donedavna vic nez 100 patchu. Ted se sice konecne zacina darit spoluprace a je to lepsi (donedavna nas upstream ignoroval), ale porad je to takovy bes, ze si nekdo na update RPM u nas troufnul naposledy v roce 2005, pokud vim.

To mě těší. Snad se podaří protlačit změny do upstreamu.

A pokud vim, zrovna ty tagy Suggests a spol. RPM umi jenom tise ignorovat, zbytek se resi jinde

No jasně, ono taky dpkg pokud vím tyhle věci neřeší, řeší je až apt, v SUSE je zase řeší libZYpp. Donedávna (možná stále) je neuměl ani OBS, protože ty tagy nedával do metadat k repu. Psali jsme report, tak už to snad někdo fixnul.

[Aleš Kapica]

To je snad prvně co jsem se zadostiučiněním četl tvůj komentář. No možná ne prvně, ale opravdu - díky za uvedení na pravou míru.

[anicka]

Inu, není zač a užij si to

Koukám, že sama nemajíc ideových nepřátel, přicházím o spoustu kladných pocitů

[Käyttäjä 11133]

Koukám, že sama nemajíc ideových nepřátel, přicházím o spoustu kladných pocitů

:D

[Aleš Kapica]

Není to o ideovém nepřátelství. Kdybych se rpm v minulosti nevěnoval tak intenzivně jako teď ty, tak bych snad podobné diskuze nechal plavat. Jenže já se v tom hrabal - abych byl schopen udělat kvalitní lokalizaci Synapticu, tak to znamenalo pochopit jak to všechno funguje. Ovšem kdybych napsal do zdejší diskuze to co ty, tak by mne okamžitě extender a spol. opět nařkli ze zaujatosti.

[bibri]

1 nevím, Marek píše že ano, 2-5 nikdy nebyly výhody debu a jestli ano, tak možná oproti .tar.gz (beru, že vývoj byl lepší občas tady, občas jinde, ale tak to je).

[David Šmíd]

Ano, RPM umí SPEC tagy "Suggests:" a "Recommends:" (synonyma). Jiná otázka je, jak jsou tyto tagy využívány nástroji vyšší úrovně. APT-RPM umí informovat o doporučených balíčcích, nicméně abych ho donutil pomocí přepínače považovat doporučené balíky za vyžadované, musel jsem ho trochu přiohnout. Jak jsou na tom v tomto ohledu yum, smart, urmpi a zypper nevím.

---

[Ilfirin]

Já si musím také rýpnout. Jako z pohledu uživatele mě nikdy rozdíl deb/rpm netankoval. Pokud jsem měl balíček pro svoji distribuci od dobrého balíčkáře, tak fungoval a mohl to být jakýkoli formát.

Vtip začal, až když jsem si v rámci dobrovolného zvedání kvalifikace zkoušel, vlastní balíčky dělat. Po pár pokusech z checkinstallem mě Marek právem sprdnul a napsal mi článek o základech rpm. A světe div se, pochopil jsem to. Mám spec, kde je definice balíčku a návod (v bashu jak už tu padlo) jak ho zkompilovat. K tomu zdrojáky a případné patche a hotovo. Hlavní kouzlo je zkrátka dobrý spec a dobrý spec neznamená jen SUSE, ale možnost s jednou sadou src.rpm vytvořit balíčky hned pro několik distribucí. Balíčkář se ze mě nakonec nestal (ale co není může být, základy mám). Spíš jsem si oblíbil "kradení spec" aneb když mi nějaký balíček chybí a v jiné distribuci je, je velká pravděpodobnost že se mi bez úprav (nebo s drobnými změnami názvu devel balíčků) podaří prohnat to BuildServicem pro moje distro.

Pak jsem si po čase řekl, že kouknu na deb. Říkám si, to bude to samé, akorát trochu jinak. No už jenom úvod, že pro balíček vytvářím adresářovou strukturu a pracně rozestrkávám soubory a že samotná definice a návod na buildění se rozkládá přes více než jeden soubor... No, názor na deb mi tohle vytvořilo rychle a ne zrovna kladný.

[MJ]

No, názor na deb mi tohle vytvořilo rychle a ne zrovna kladný.

Mně naopak velmi silný negativní názor na RPM vytvořilo to, že je to jakýsi podivný binární formát, který se nedá standardními nástroji rozbalit (když pominu metodu "najděte si gzipovou signaturu a až do té usekněte hlavičku"). Sice už jsem mu to asi prominul, ale ještě ne úplně, protože za tím nevidím žádný rozumný důvod.

[Käyttäjä 11133]

JJ, to mě taky trošku mrzí :'-(

[bibri]

Hmm, to je opravdu argument, podivný binární formát, který se nedá standardními nástroji rozbalit. Na co mi to (a komu jinému) je? Co je to za argument? Jsou tu na to toolsy, dají se používat, je to prostě specializovaná věc jako každá jiná. Gz i Bz2 je taky divný binární formát z pohledu uživatele čistého taru, nebo ne?

[Aleš Kapica]

Jednoduchá odpověď - nelíbí se ti to? Nepoužívej! A Ubuntu není Debian. To že také používá apt neznamená že je to stejná distribuce. Ano, dají se vzájemně řezat. Také jsem to nějaký čas dělal - do té doby než jsem pochopil, jak se vlastně ty balíky dělají.

Ad tvůj příklad srovnání výpisů - tebe třeba nezajímá co ti ten balík chce říct, ale mě ano! Protože já netoužím po tom aby mi nějaký balík kvůli nějaké přihlouplé závislosti rozdrbal to co mi funguje. Chci vědět co chce nainstalovat, a stejně tak chci vědět proč něco nainstalovat nechce. Balíky dělají jen lidé a ti nejsou neomylní. Na rozdíl od rpm lze však deb balíčky poměrně jednoduše opravit.

U Mandrivy kamarád při přechodu na novější verzi končil pravidelně s polovinou nefunkčního systému a pak to pracně dolaďoval. Stejně tak dopadal i u Ubuntu. Proto přešel na Debian.

Já když aktualizuji systém, který leží někde bůhví kde a ne mi pod stolem, tak si prostě nelajznu že mi po rebootu skončí na nějaké pitomině a já už se na něj nepřihlásím. Debian mi tohle za celou dobu co ho používám nikdy neudělal.

[bibri]

Jednoduchá odpověď - nelíbí se ti to? Nepoužívej! A Ubuntu není Debian. To že také používá apt neznamená že je to stejná distribuce. Ano, dají se vzájemně řezat. Také jsem to nějaký čas dělal - do té doby než jsem pochopil, jak se vlastně ty balíky dělají.

Diskuse není Ubuntu vs. Mandriva, ale deb vs. rpm. Ubuntu používá deb, proto si ho beru do huby.

Ad tvůj příklad srovnání výpisů - tebe třeba nezajímá co ti ten balík chce říct, ale mě ano!

To jsem neřekl - hlášení balíku je důležitá věc a urpmi ho vypisuje.

Protože já netoužím po tom aby mi nějaký balík kvůli nějaké přihlouplé závislosti rozdrbal to co mi funguje. Chci vědět co chce nainstalovat, a stejně tak chci vědět proč něco nainstalovat nechce.

Ani to jsem neřekl. Myslím, že jsem poměrně jasně specifikoval, co se mi nelíbí. Obě výše uvedené věci vědět chci a urpmi mi je napíše, protože jsou důležité. Nedůležitá jsou hlášení o tom, že apt-get něco zpracovává strom apod., to ať si schová pro --verbose...

Balíky dělají jen lidé a ti nejsou neomylní.

Souhlas.

Na rozdíl od rpm lze však deb balíčky poměrně jednoduše opravit.

Nechápu - to je starost správce balíku, ne moje. Nemůžu opravovat všechny pokažené věci.

U Mandrivy kamarád při přechodu na novější verzi končil pravidelně s polovinou nefunkčního systému a pak to pracně dolaďoval. Stejně tak dopadal i u Ubuntu. Proto přešel na Debian.

Nijak to nedemonstruje technickou kvalitu a převahu debu, spíš naopak. Přímo to koresponduje s jedním s posledních odstavů mého dlouhého blogpostu.

Já když aktualizuji systém, který leží někde bůhví kde a ne mi pod stolem, tak si prostě nelajznu že mi po rebootu skončí na nějaké pitomině a já už se na něj nepřihlásím. Debian mi tohle za celou dobu co ho používám nikdy neudělal.

Nenavážím se do Debianu, ale do fanatických diskusí na téma deb vs. rpm, kde nejčastější a nejviditelnější argument je "rpm sucks, deb rulez" - zcela nepodložený a nesmyslný.

[JKK]

nemůžu si pomoct, ale v celé diskuzi nerozlišujete mezi distribucí a konstrukcí balíku. Zde se bavíme o typech balíku a vy sem pořád taháte Debian a stylizujete se do role ochránce distribuce, do které mi všichni kopou. Tak to přeci není. Nejde ani o Debin ani o APT. Jde o DEB a RPM

[Aleš Kapica]

Viz výše. Jinak mně přijde zajímavé že s problémem dependency hell přicházejí většinou "spokojení" uživatelé rpm based distribucí.

[bibri]

Z vlastní zkušenosti mohu říci, že poloviny těchto problémů mají na svědomí chytrolíni radící uživatelům, aby si odněkud stáhli balíček nebo aby si něco zkompilovali. Proboha proč, když tu deset let máme vynález jménem repozitář?

Druhou polovinu dělá zkušenost z Windows - stáhnout exe, nainstalovat. Jenže to jaksi nejde a nepůjde to ani s deby, že ne? Navíc se do toho promítá fakt, že nejvíc user friendly jsou rpm-based distra a uživatelé začínají nejčastěji právě na nich.

Nepamatuji si, kdy bych narazil na jiný než uvedený problém s dependency hell - a podpory dělám docela dost. Kdo používá repozitáře, žádné problémy nemá.

[David Šmíd]

Mohl bys mi nějak osvětlit, co to vlastně je "problém dependency hell" ? A jak k jeho výskytu může vůbec dojít, pokud používám manažer balíčků typu apt-rpm, smart, urmpi, zypper, yum apod. a NEPOUŽÍVÁM rpm switch --nodeps ? Nějak mi připadá, že to je chiméra, kterou už dlouho nikdo neviděl, ale všichni se s ní zaklínají.

---

[extender]

Na problém Dependency Hell jsem narazil jen v jediném neustále se opakujícím případě. A to při výkřicích ubuntistů a Debianistů o sračkovosti RPM. Nenarazil jsem na žádnou diskuzi, kde by někdo vykládal něco o DEB suxx RPM rulezz. RPM neustále haní uživatelé DEB balíčků!

[David Šmíd]

Na rozdíl od rpm lze však deb balíčky poměrně jednoduše opravit.

Nějak nechápu co je tak složitého na opravě RPM balíčku ? Nainstaluji si zdrojový balíček, opravím .spec soubor podle svého a zadám rpmbuild -bb balik.spec. Hotovo.

---

[MJ]

GZ i BZ k tomu mají svůj důvod (ukládají něco, na co dosud žádný formát neexistoval), u RPM tento důvod ani přinejmenším nevidím.

[extender]

A co by jste si jako představoval? Na co tady máme bz když máme Gz. Na co tady máme Cpio když máme Tar. Preferujete jedinou správnou cestu ála Microsoft?

[MJ]

Nikolivěk. Ale když je balíček v podstatě archiv s metadaty, měl by být uložen v nějakém archivačním formátu. Klidně třeba novém, kdyby žádný starý nevyhovoval. Jenže archivace a správa balíčků jsou dva docela dobře oddělené problémy, tak by měly být oddělené i na úrovni formátu souboru. Ona ta stará dobrá unixová filosofie "nechť program dělá jen jednu věc, ale pořádně" má stále něco do sebe.

[bibri]

Buď jsem to nepochopil, nebo věta "Jenže archivace a správa balíčků jsou dva docela dobře oddělené problémy, tak by měly být oddělené i na úrovni formátu souboru." dle vás opodstatňuje rpm jako samostatný formát souboru (tedy balíček/archiv). Proč proti němu tedy protestujete větou, že by stačil tgz nebo bz2?

[MJ]

Oddělenost jsem myslel tak, že to jsou dvě různé vrstvy, které se mají implementovat samostatně a stavět jedna na druhé, nikoliv že jsou to zcela nesouvisející problémy.

Myslím, že dobrý důvod před chvílí ukázal Kyosuke svou zmínkou o kompresi LZMA. Kdyby byl balíčkovač stavěn nad archivátorem, pak stačí novou kompresi dodělat do archivátoru a bude ji používat nejen balíčkovač, ale také spousta dalších programů.

[Kyosuke]

Kdyby byl balíčkovač stavěn nad archivátorem, pak stačí novou kompresi dodělat do archivátoru a bude ji používat nejen balíčkovač, ale také spousta dalších programů.

Ale vždyť tak je to implementované? RPM balík od nějakého místa snad není nic než jiného než CPIO soubor něčím komprimovaný (gzip, bzip2...). Jenže problém s LZMA je, že existují snad minimálně dva (dokonce myslím, že snad tři) způsoby, jak ten stream uložit do souboru, a netuším, jak se řeší takové věci, jako je dekomprimovatelnost streamu ve více vláknech. (LZMA ji podporuje - tedy v p7zipu - a to velice efektivně, jestliže LZMA je podstatně rychlejší než bzip2 i na jednom jádře, pak dvoujádro (alespoň mně) skrouhne z wallclock time dalších asi čtyřicet procent.) A nejsem si jist ani tím, jak moc je momentálně stabilní. S největší pravděpodobností by i při přímém použití formátu .tar.lzma musel být předepsaný konkrétní software a jeho verze, jak moc by si tím člověk pomohl?

Jinak, přiznám se, že účely archivace velkého množství dat (bez potřeby zachování některých atributů) používám čistě 7z. Má takovou docela pěknou fíčuru, v solid režimu seřadí za sebe soubory s podobným obsahem (nevím, jestli podle hlaviček nebo přípon - každopádně to v praxi znatelně funguje), takže ten slovník se mezi jednotlivými soubory skutečně dokáže účinně recyklovat. Netušíš o něčem podobném pro tar?

[MJ]

Ale vždyť tak je to implementované? RPM balík od nějakého místa snad není nic než jiného než CPIO soubor něčím komprimovaný (gzip, bzip2...).

... jen kdyby do tohoto místa nebyly v souboru nabastlená metadata v úplně jiném formátu. Přitom by bylo tak jednoduché (a stejně efektivní) uložit je jako první soubor do archivu.

Netušíš o něčem podobném pro tar?

Zatím jsem nic takového neviděl. Ale stálo by za to propojit tar s třídící heuristikou z GITu

[bibri]

To ještě nic neznamená. Stejně tak by se dalo tvrdit, že gz i bz2 jsou zbytečné, protože máme (měli jsme) compress. Mimoto rpm je starší než bz2.

[Aleš Kapica]

A bz2 používá v deb balíčcích Ubuntu a ne Debian.

[MJ]

To ještě nic neznamená. Stejně tak by se dalo tvrdit, že gz i bz2 jsou zbytečné, protože máme (měli jsme) compress.

Jenže GZ i BZ2 přinášejí oproti compressu něco nového (účinnější kompresi), zatímco RPM oproti archivačním formátům zhola nic.

Mimoto rpm je starší než bz2.

Jak to spolu souvisí?

[Kyosuke]

Jenže GZ i BZ2 přinášejí oproti compressu něco nového (účinnější kompresi), zatímco RPM oproti archivačním formátům zhola nic.

Momentálně proti nim přináší třeba LZMA, kterážto komprese (o dost účinnější a rychlejší než BZ2) snad kromě 7z formátu standardní kontejner zatím nemá.

[MJ]

TAR+LZMA? (Myslím, že v poslední verzi GNU taru na něj už je i switch...)

[David Šmíd]

Všechno má svůj důvod. RPM formát je hlavička + cpio.gz.
Výhoda tohoto uspořádání je v tom, že přístup k datům v hlavičce je velice rychlý a jednoduchý. Dnes to možná nehraje takovou roli, ale v dřívějších dobách se dbalo na efektivitu.

---

[MJ]

Hlavička by úplně stejně dobře mohla být uložena v tom cpio.gz jako první. Pak by byl přístup k ní prakticky stejně efektivní.

[David Šmíd]

To myslíš vážně ? Že jedno volání "head" je co do efektivity ekvivalentní rouře "gunzip | cpio | head" ? Uvědomuješ si vůbec, že data v cpio.gz jsou komprimována ?

---

[MJ]

Uvědomuji si to docela dobře

Přečtení té hlavičky není rozhodně volání head, protože dopředu nevím, kolik těch dat bude. Na extrakci souboru samozřejmě nepotřebuji volat spoustu externích programů, mohou to klidně být knihovny. Dekomprese GZIPu je oproti fyzickému čtení dat z disku záležitost okamžiku.

[David Šmíd]

Samozřejmě, že by se to nedělalo externími programy, samozřejmě, že je to záležitostí okamžiku, nicméně stále platí, že je to složitější a že je to pomalejší. Byly doby, kdy to hrálo svoji roli. Mě je to celkem šumafuk, jen vysvětluji, kde se to tam vzalo.

---

[MJ]

Doby, kdy by takový rozdíl v rychlosti byl znatelný, sice byly, ale určitě víc jak 10 let před RPM

[MJ]

(Jen dodávám, že chápu, že to byl důvod, proč se k tomu autoři rozhodli, ale současně jsem přesvědčen, že je to důvod naprosto scestný.)

[anicka]

Hmm, to je opravdu argument, podivný binární formát, který se nedá standardními nástroji rozbalit. Na co mi to (a komu jinému) je? Co je to za argument? Jsou tu na to toolsy, dají se používat, je to prostě specializovaná věc jako každá jiná.

To je náhodou dost důležitý argument. Já se se susím (skoroforkem ) RPM (křáp jeden pitomá, zatracená, dejte mi deby a políbím Vám ruce... no nic, už mlčím) potýkám denně (vlastně poslední tři roky nedělám skoro nic jiného), o jeho přednostech a nedostatcích vím všechno, co jsem nikdy vědět nechtěla, z vlastních zkušeností i z každodenních mailinglistových dobrodružství jiných... ale kdybych měla vybrat jednu nejpitomější a nejotravnější vlastnost RPM, určitě zvolím tenhle bláznivý formát.

Jasně, jsou na to tooly. Jejich používání je ale řádově otravnější než používání taru. Při práci s RPM si prostě pořád připadám, jak kdybych psala zdroják v OpenOfficech Bohužel zatímco na psaní zdrojáků máme i vim, na rozumnou práci s RPM máme houbeles.

[extender]

Dobrý den.

Mě jako end-userovi to může být jedno, ale smím se tedy zeptat, když je to s tím RPM pro balíkáře tak hrozné, proč už jste dávno ten fork neudělali nebo nepřešli (v nejfantasmagoričtějších snech) na DEB ?

[Ilfirin]

Přidávám se k dotazu.

[Käyttäjä 11133]

1. Protože kdyby udělali fork tak by nepřešli na deb, ale udělali vlastní balíčkovací systém založený na původním RPM. To je podstata forku.

2. Není RPM náhodou součástí LSB? AFAIK je a proto, pokud by chtěli dodržet LSB (což je u enterprise distribuce žádoucí), tak by tam stejně RPM mělo být.

[extender]

Napsal jsem buď fork a nebo DEB, né současně

[anicka]

To by bylo na strašně dlouhé povídání... navíc v SUSE o tomhle rozhodují úplně jiní lidi a já to jen tak sleduju. Ale zkusím říct, co si o tom myslím, třeba to nebudou úplné bludy - když jo, tak si toho nejspíš časem někdo všimne a uvede to na pravou míru

Fork je něco, co se dělá až v případě největší nutnosti, protože to je v dlouhodobém měřítku náročné (a v SUSE tedy i drahé). Takže se do toho pochopitelně nikomu moc nechce - z okna se taky skáče teprve když už není kam utéct před kouřem.

Osobně si myslím, že kdyby jednou přišla chvíle, kdy bude nutné vydat se vlastní cestou, spíš než forkem RPM skončíme u něčeho vlastního, co odstraní nedostatky RPM a bude ho jen emulovat kvůli LSB. A moc by se mi to líbilo - myslím, že máme lidi, kteří mají na to, udělat konečně něco, co funguje.

Přejít na debianí balíčky by nám moc nepomohlo, jelikož by to mělo taky své nevýhody (už si teď moc nepamatuju podrobnosti, opravdu teď deby moc nepotkávám - ale minimálně bychom asi neuměli tak pěkně updatovat). Navíc je tu ta LSB, takže bychom RPM stejně museli minimálně předstírat.

[Kyosuke]

A moc by se mi to líbilo - myslím, že máme lidi, kteří mají na to, udělat konečně něco, co funguje.

<rejp> Doporučuju lidi z libzyppího teamu, ti nedávno prokázali, že skutečně dokážou dělat věci, které "konečně fungují". </rejp>

[ss]

<rejp>http://www.abclinuxu.cz/serialy/instalace-softwaru-v-linuxu</rejp>