Portál AbcLinuxu, 8. května 2025 16:58
RPM vs. DEB je jedním z trvalých náboženských flamewarů ve světě Linuxových distribucí. Přitom samotný formát balíčku je zcela nepodstatnou vlastností. Ale už i ten leží Debianistům v krku, protože RPM údajně není rozbalitelný "standardními nástroji". Jako by byl nějaký principielní rozdíl mezi tarem a rpm2cpio, zvlášť když RPM balík může browsovat každý uživatel midnight-commanderu. (což se mi mimochodem s balíkem formátu DEB nepodařilo, nevím proč když je to tar).
Téměř národním sportem Debianistů se stalo šíření fudu o jakémsi RPM-hellu, který jsem nikdy nepotkal, nikdy neviděl, zřejmě jsem v uplynulých letech málo zlobil
. Protože je tento propagandisticky axiom asi věčný, byl bych rád, kdyby mi konečně někdo vysvětlil, co je to vlastně ten RPM-hell, kterým Debianisti straší malé děti, a jak souvisí s RPM jako formátem balíčků nebo RPM jako nástrojem pro práci s balíky. Vždycky jsem si myslel, že dependency hell nemá nic společného s formátem balíků, ale naopak je způsobem politikou tvorby a správy balíčků a repozitárů.
Nejpodstatnějším rozdílem mezi oběma platformami jsou bezesporu samotné nástroje pro tvorbu a správu balíků. I mezi Debianisty existuje jen málo lidí, kteří nebudou souhlasit s tím, že vytvořit RPM balík je snazší než vytvořít balíček DEB. Na čem už se ale oba tábory neshodnou jsou přednosti a nevýhody RPM vs. DPKG. Opensource je sice o svobodě volby, přesto jsem osobně nikdy nepochopil, co má být na DPKG skvělého, nebo alespoň výhodného. Nevím, kterého vola napadlo nacpat konfiguraci balíku natvrdo do instalačního procesu. Jaký má proboha smysl mít X různých stavů balíku v systému? DPKG je evidentně největší hovadina, kterou v Debianu kdy vymysleli! Syntaxe příkazů tohoto nástroje je občas naprosto nemožná. Když jsem před nedávnem asistoval kamarádovi s rozbitou DPKG databází, která zkolabalova po výpadku elektřiny během instalace, měl jsem pocit, že si ze mě snad někdo dělá prdel. Help tohoto nástroje zrovna moc nápomocný není a dodnes ani po následném googlování nevím, jakým způsobem opravit dpkg databázi. Nevím proč by systém měl zůstat na lopatkách jen proto, že se mu rozbila instalace několika stovek nepodstatných balíků typu kdelibs, které nemohou mít na funkci dpkg a aptitude žádný vliv! Co na tom, že DPKG používá pomalou human-readable textovou databázi, ve které stejně aby se prase vyznalo! RPM s výkoným database backendem je nejen podstatně rychlejší, ale hlavně v případě problémů uživateli nabízí rebuilddb, a nabízí mu to zcela viditelně v helpu. Rpm --rebuilddb jsem v případě poškození databáze použil již několikrát a asi mám štěstí, protože to fakt funguje. DPKG je tak inteligentní toolsa, že dokonce ochotně uvede systém dostavu s nesplněnými závislostmi, aniž by vůbec protestovala.
Nejvýše v celé struktuře stojí toolsy řešící závislosti mezi balíky. Vývojáři volili mezi Fedorou a Debianem, byla to tedy tak trochu volba YUM vs. Apt-get. Opět nevím co je na Aptu tak skvělého. Závislosti neumí skvěle řešit ani jeden, na rozdíl od YUMu má ovšem APT dost podivnou syntaxi příkazů, a přímo hrůzostrašný informační výstup. Navíc pro RPM existuje jak APT, tak i celá řada lepších nástrojů z nichž pouze SMART podporuje také DEB.
Proč tedy tolik povyku okolo Meego? Co je na tom tak strašného, že zvolili RPM? RPM/RPM je v současné evidentně v lepší kondici než DPKG/DEB. Umí závislosti na souborech, umí rozdílové balíky, umí provést verifikaci balíku. Největší skupina upstream vývojářů používá RPM distribuce. Většina nezávislých distribucí si zvolila RPM, neexistuje žádná distribuce adoptující DPKG. Stovky klonů Debianu si zvolily Debian kvůli Debian Policy a kvůli obrovské zásobě balíčků v jednotném Debianím repozitáři, rozhodně né kvuli formátu balíčků. Milí Debianisté. Není tedy možné, že za volbou RPM je něco úplně jiného než temné politické spiknutí? Je tak těžké si přiznat, že RPM může být v tuto chvíli výhodnější?
Tiskni
Sdílej:
14.3.2010 17:17
vlastikroot | skóre: 24
| blog: vlastikovo
| Milevsko
14.3.2010 17:20
vlastikroot | skóre: 24
| blog: vlastikovo
| Milevsko
14.3.2010 18:21
brk | skóre: 29
| blog: broukoviny
Opět nevím co je na Aptu tak skvělého.Je toho ještě hodně co nevíš.
dpkg: chyba při zpracovávání firefox-gnome-support (--configure): problém se závislostmi - nechávám nezkonfigurované dpkg: nesplněné závislosti zamezily konfiguraci balíku libgnome-vfs2.0-cil: libgnome-vfs2.0-cil závisí na libgnomevfs2-0 (>= 1:2.17.90); avšak: Balík libgnomevfs2-0 zatím není zkonfigurován. dpkg: chyba při zpracovávání libgnome-vfs2.0-cil (--configure): problém se závislostmi - nechávám nezkonfigurované dpkg: nesplněné závislosti zamezily konfiguraci balíku ubuntu-docs: ubuntu-docs závisí na yelp; avšak: Balík yelp zatím není zkonfigurován. dpkg: chyba při zpracovávání ubuntu-docs (--configure): problém se závislostmi - nechávám nezkonfigurované dpkg: nesplněné závislosti zamezily konfiguraci balíku gwibber-service: gwibber-service závisí na python-desktopcouch-records; avšak: Balík python-desktopcouch-records zatím není zkonfigurován. dpkg: chyba při zpracovávání gwibber-service (--configure): problém se závislostmi - nechávám nezkonfigurované dpkg: nesplněné závislosti zamezily konfiguraci balíku libgnome2-vfs-perl: libgnome2-vfs-perl závisí na libgnomevfs2-0 (>= 1:2.17.90); avšak: Balík libgnomevfs2-0 zatím není zkonfigurován. dpkg: chyba při zpracovávání libgnome2-vfs-perl (--configure): problém se závislostmi - nechávám nezkonfigurovanéSe kterým nejsem schopen vůbec nic udělat. Podle mě je evidentní, že tolik stavů balíků v Debianu zrovna moc produktivní není.
15.3.2010 15:48
xxx | skóre: 42
| blog: Na Kafíčko
15.3.2010 15:51
xxx | skóre: 42
| blog: Na Kafíčko
No zkusil jsem udělat takový hardcore test RPM vs. DPKG ve Virtualboxu. V obou případech jsem udělal upgrade asi 500 balíků s tím, že uprostřed instalace jsem stroj natvrdo zresetoval. Tento test jsem u obou nekolikrát zopakoval.Nic proti, ale v reálu by podobně postupoval jenom idiot. Vyzkoušejte si to spíše na jiném, reálném příkladu. Máte stroj Debian Sarge a potřebujete ho aktualizovat na aktuální Debian Lenny (Ekvivalent pro Fedoru - s Fedora Core 4 na Fedora Core 11). Akci je třeba provést vzdáleně po síti na stroji kdesi v serverhousu. A včil mudrujte co je lepší..
Máte stroj Debian Sarge a potřebujete ho aktualizovat na aktuální Debian Lenny (Ekvivalent pro Fedoru - s Fedora Core 4 na Fedora Core 11).Ani v jednom případě bych si to nelajznul bez ILO/KVM
Jen tak mimochodem, po celoodpoledním hraní jsem se dopracoval do stavu, kdy mám v systému 2 rozbité balíky u kterých dpkg -r --force-all tvrdí, že pre removal skript vrátil chybový status 2. Jsem těžce v prdeli, protože dpkg je odmítá remove i purge jen proto, že mají nějaký rozbitý skript, místo toho aby je prostě bez odmlouvání vymlátil (na co je tam do háje --force-all, když to k ničemu není!). Aptitude pustit nemůžu, protože mi kvuli těmto balíkům bude chtít cpát 30 dalších, které nechci, apt-get pro jistotu odmítá udělat cokoli a doporučuje mi apt-get install -f, které ovšem zkončí na tom, že dpkg post removal skript error 2. Takže mám rozesraný Debilan, a hřeje mě potěšení, že za 5 let na něm budu moci udělat dist-upgrade, a ty dva nezkonfigurované, neodinstalovatelné balíky mě tam budou strašit i potom
Řekl bych, že ten mnou nastíněný mnohem více odpovídá realitě.
Všechny zbývající balíky, které dpkg odmítalo odinstalovat kvůli chybe skriptu jsem lokalizoval ve /var/lib/dpkg/status a natvrdo o nich vymazal všechny záznamy. Následně jsem se přesunul do /var/lib/dpkg/info, kde jsou další informační soubory a ty jsem zlikvidoval také.
čekal jsem, že systém přestane s těmito balíky otravovat, protože pro něj přestanou existovat. Ale ono ne. Příkaz apt-get autoremove, kterým jsem chtěl prověřit, zda nezůstaly nějaké nadbytečné balíčky způsobil to, že se ty dementní balíčky, co mě celý den otravovaly najednou zkonfigurovaly (jak to, když jsem je vyházel z databáze?). A pak jsem je vyhodil. Po ceodním boji jsem zvítězil na dpkg, prasáckou alchymií, ani nevím jak.
Jsem rád že zůstanu u RPM.
aptitude upgrade. Je to taková loterie...
Problém je totiž v tom, že současné verze debianu a ubuntu obsahují příliš komplikovaný graf virtuálních balíčků, závislostí a protizávislostí, které se navíc mohou další týden zcela změnit (v testingu). Při určité konstelaci se prostě pravidla (depends vs. conflicts) dostanou do takového stavu, že je prostě vyřešit nelze - něco musí pryč.
Můžeme jenom nostalgicky zavzpomínat na časy, kdy takovéto problémy neexistovaly. A nebo se porozhlédnout jinam (mimochodem: gentoo ne, tam takovýto bordel dorazil mnohem dříve).
15.3.2010 20:13
Jakub Lucký | skóre: 40
| Praha
15.3.2010 21:53
Jakub Lucký | skóre: 40
| Praha
16.3.2010 12:45
Jakub Lucký | skóre: 40
| Praha
apt-get upgrade fungovalo vždy a na první pokus.
Jinak v Debianu je to obvykle výměna kus za kus, nikoliv pouhé odebrání (náhrada gnome-session za gnome-session-common a gnome-session-bin atp.)Až na to, že u spousty balíků zůstanou závislosti na gnome-session a pro jistotu ještě s číslem verze, aby to náhodou nemohl aptitude spravit.
Horší je když aptitude skončí s chybou že nějaký balíček nemůže být zkonfigurován, protože vyžaduje určitou závislost kterou nelze splnit. Pak nastupuje analýza závislostí a dpkg --forcePřesně tenhle problém jsem vyrobil při svém pokusu (viz výše). Mohl by mi někdo vysvětlit co s tím? Balík nešel zkonfigurovat, kvůli nesplněným závislostem, ani odstranit, kvůli poškozenému pre-uninstall skriptu. Přepínače --force-all k odstranění ani konfiguraci nevedl..
aptitude -f install doběhne.
Jiná věc je, pokud některý script (preprm, preinst, atd) skončí s chybou, pak je možné je editovat v /var/lib/dpkg/info/ a opravit. Případně, jako nejdrsnější metoda odstranění balíčku, přímo zeditovat /var/lib/dpkg/status a vymazat stopy (a ručně provést smazání souborů, samozřejmě).
16.3.2010 15:10
Jakub Lucký | skóre: 40
| Praha
Což mě docela štve.
14.3.2010 17:53
build nějak pozná, jakou verzi formátu má použít, když builduje pro starší verzi distribuce.
build poradí, jinak by to byl docela průšvih (asi bych si na to musel udělat virtuály).
Nebo budeš na lennym dělat balíky pro sarge, nebo naopak? Bez chrootu? Linkovat proti jiným verzím distribuce? :)
build.
build nějak nepoznal, který definiční soubor má použít, a muselo se mu to říct ručně).
14.3.2010 17:46
danaketh | skóre: 6
| blog: Sick Mind
| Praha
15.3.2010 00:23
Jezekus | skóre: 19
| blog: jezkova_nora
15.3.2010 01:11
danaketh | skóre: 6
| blog: Sick Mind
| Praha
14.3.2010 22:26
Jakub Lucký | skóre: 40
| Praha
15.3.2010 17:02
rudiik | skóre: 16
| blog: rudiikuv miniblog
16.3.2010 17:58
pavlix | skóre: 54
| blog: pavlix
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.