RPM - Best packaging tools.

14.3.2010 17:12 | Přečteno: 1320×

Moblin, původně Intelova distribuce pro mobilní zařízení, se před nějakou dobou rozhodl upřednostnit RPM jako formát pro své balíčky. Fanoušci DEBů protestovali. Nyní se s Moblinem (RPM / GTK) sloučilo Maemo (DEB / Qt), a vzniklý projekt Meego logicky musel udělat kompromis. Je pochopitelné, že vývojáři zvolili z jejich pohledu nejvýhodnější variantu - RPM a Qt. Fanoušci debů v diskuzích ale i devel mailing listech Meego začínají být hysteričtí. Ani předchozí změna preference Nokie z GTK na Qt (po odkoupení Trolltechu logický krok) nevyvolala takovou hysterii jako RPM. Rozhořčení fanoušci dpkg a apt-get na telefonech Nokia N900 vyhlašují do budoucna kategorický bojkot této plaformy. Proboha proč?

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ší?        

Komentáře

[vlastikroot]

RPM i DEB smrdí, pkg.tar.gz rulez!

[haha]

Emerge a Packman Rulezzz

[vlastikroot]

Pacman woe pacman!

[brk]

To byl jen test pozornosti, uspěls. ;o)

[Aleš Kapica]

Opět nevím co je na Aptu tak skvělého.

Je toho ještě hodně co nevíš.

[haha]

Já se taky rád dozvím, co že to vlastně ten Apt umí tak skvělého že předčí všechny ostatní

[Aleš Kapica]

Tak se ho nauč používat a přijdeš na to sám

[haha]

žádné velké rozdíly ve schopnostech nevidím.

Ale zeptal bych se na jinou věc. Dejme tomu, že pomocí dpkg-reconfigure debconf nastavím Debian frontend na neinteraktivní a prioritu na kritickou. Tím bych měl zřejmě docílit implicitního chování RPM, které při instalaci neklade otázky, a balíky instaluje s nějakým výchozím nastavením. Zajímalo by mě, jak ty balíky budou vypadat? Budou mít status nezkonfigurovan nebo zkonfigurován? Jak dopadne Debian systém, pokud toto nastavení zůstane natrvalo? Neskončím po roce s rozbitým polofunkčním systémem?

[Aleš Kapica]

Jsem blázen abych instaloval balíky aniž bych chtěl vědět co se chystají udělat? Nicméně ano, lze instalovat balíky s tím že nechám vše na instalátoru (výchozí volba je že ponechá původní konfiguráky). V takovém případě si pak je nutno případné problémy pořešit ručně.

[haha]

RPM instaluje vše automaticky, a problémy to samo o sobě nedělá. To že dpkg ponechá původní konfiguráky znamená co? že provede implicitní nastavení? Nebo že ponechá konfigurák, který mi tam zůstal odminule? A co když je to první instalace?

[Aleš Kapica]

Nevím jak teď, ale v době kdy jsem byl nucen s RPM distribucemi to problémy dělalo.

Právě proto je u deb balíků vícestavová instalace, aby člověk neskončil s nefunkčním systémem. Pokud se při instalaci nevyskytne žádný problém, nebo není v preinstall skriptu řečeno jinak ponechá původní konfigurák, resp. se zeptá jesli má či nemá konfigurák nahradit tím z balíku. Nechci se do toho tady více pouštět, kdo hledá najde a na wikibooks už jsem to jednou psal. Logicky - je-li to první instalace, tak se spustí (je-li to nutné) konfigurační skript. dpkg-reconfigure je od toho, aby umožnil balík rekonfigurovat, pokud admin něco zvrže.

[haha]

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. Výsledky jsou poměrně přesvědčivé:

RPM přežilo úplně všechno, včetně opakovaného resetu uprostřed stejného upgradu. V některých případech na konci úspěšné instalace vyhodilo chybu databáze což opravil rpm --rebuildb.

DPKG ve všech případech skončilo s rozbitou databází, různými hláškami o neexistujících souborech nebo skriptech, protesty s instalací některých balíků z důvodu nesplněných závislostí jiného balíku, který je nainstalován, ale nelze zkonfigurovat protože mu prý chybí jiná závislost. Aptitude je úplně bezzubý a neumí navrhnout žádné řešení. Apt-get install -f nikam nevede, dpkg --configure -a také ne. Instalace vždy končí nekonečným výpisem typu (ve skutečnosti mnohokrát delším) :

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í.

[xxx]

To ze neumite s dpkg jeste neznamena, ze je to horsi nastroj. Doporucuju se zamerit zejmena na prepinac --force a --ignore-depends. Navic to, ze se vam opravila ona rpm databaze neznamena, ze mate system v konzistentnim stavu.

[xxx]

A mimochdem, pred opetovnym pokusem o instalaci. Pustil jste nejdrive prave ono "dpkg --configure -a", coz by udelal kazdy kdo dpkg neco vi.

[haha]

"dpkg --configure -a" jsem začal. Přepínač "--force-all" mi v žádné následné variantě nebyl k ničemu platný. Ať cokoli instaluju nebo odinstaluju, vždy má dpkg hromadu problémů. A když nakonec pomocí dpkg -r --force-all vyhážu všechny nezkonfigurované balíky, aptitude i apt mi je cpou automaticky pořád zpátky, ale když je nainstaluju, nejdou zkonfigurovat.

[alkoholik]

Ono se to moc nevi, ale RPM pouziva pro upgrady balicku transakce. Takze bych se konzistentni databazi a systemu moc nedivil. Viz http://www.linuxjournal.com/article/7034.

[Aleš Kapica]

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ší..

[Käyttäjä 11133]

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

[Aleš Kapica]

Shrnul bych to jinak - u RPM distribuce bych si to nelajznul vůbec. Aby bylo jasné - hovořím o zcela konkrétním úkonu, který jsem dělal. Kde ten server fyzicky leží netuším, v životě jsem ho neviděl. Měl jsem k dispozici pouze rootovský přístup. Neříkám že u toho není adrenalin (Naběhne? Nenaběhne?..), jenže u Debianu je právě díky vícestavové instalaci mnohem větší pravděpodobnost, že pokud něco fakt nezvržu tak naběhne. Chce si to především dobře ohlídat nastavení zavaděče a instalaci jádra.

[Aleš Kapica]

U RPM distribuce bych totiž raději rovnou zvolil čistou instalaci.

[haha]

RPM distribuce dist-upgrade běžně podporují, logicky o jednu verzi. Vámi navrhovaných 7 verzí fedory považuju za dost špatný vtip.

I kdyby byl dist-upgrade absolutně nemožný, nevím proč bych měl brát jako výhodu mít systém, co za 5 let možná udělá bez problému dist-upgrade, ale nejde u něj opravit databáze balíčků

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

[Aleš Kapica]

Hovořili jsme o hardcore testu ne? Řekl bych, že ten mnou nastíněný mnohem více odpovídá realitě.

[Aleš Kapica]

Za podobnými problémy většinou vězí nějaký zapomenutý postinstall skript. Obvykle stačí pozorně přečíst co ten apt vypisuje.

[haha]

já to čtu. Je to pořád dokola. Mám 20 rozbitých balíků, které nejdou zkonfigurovat. Dpkg hlásí, že závisí na jiných balících, které nejsou zkonfigurovány atd...

Pomocí dpkg -r --force-all všechny problémové balíky vyhážu, a zůstanou mi dva, které nejsou vyhodit, protoře pre removal skript error status 2. Doporučí mi apt-get install -f. Když to udělám, apt mi nasere znova tytéž balíky, které jsem tak pracně vyházel, a které nejdou zkonfigurovat a jsem tam kde jsem byl.

Já prostě nechápu, proč nemůže dpkg ty dva rozbité balíky vyhodit. žádný balík je nepořebuje! Prostě by vymazal všechny soubory, a odstranil všechny jejich skripty. Nakonec do dopadne tak, že budu muset dpkg obejít, vyhodit všechny jejich soubory, vlézt do /var/lib/dpkg/status, a vymazat ty dva zmetky ručně. A následně se modlit, ať si dpkg nevymyslí něco jiného.

[Aleš Kapica]

Za takový problém nemůže apt, ale balíkář a může se to stát u kteréhokoliv distra. Ovšem u aptu u toho nekončíte s nefunkčním systémem.

[haha]

Balíkář za to může i u RPM. Nicméně podařilo se mi to prasácky opravit. Teď bych byl ještě rád, kdby mi někdo vysvětlil, co že jsem to vlastně provedl

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.

[Aleš Kapica]

Au.

[haha]

Přesně tak. Au. Dneska už pokusný systém dosloužil. Asi jsem ho pročistil moc

Jsem rád že zůstanu u RPM.

[Aleš Kapica]

A pokud možno u něj zůstaň navěky..

[podlesh]

No, ono to až tak nereálné není: dostat databázi balíčků do popisovaného stavu není dnes nijak těžké a v testingu se tos nenulovou šancí se to povede při každém 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).

[Aleš Kapica]

Ano. V testingu je tato šance opravdu nenulová. Proto taky používám už pět let unstable. Situaci, kdy jsem se naposled dostal do podobné situace jsem podchytil tady v blogpostu 29.9.2009 . Podotýkám že to bylo způsobeno balíky z experimentalu a týkalo se to mé pracovní instalace na notesu. Zásadní chybu kvůli níž by mi stroj nenajel vůbec, už dlouho nepamatuji.

[podlesh]

No, já nemluvím o situaci kdy stroj nenajede (to jsem debianu skutečně ještě neviděl), ale o situaci kdy bez ručního zásahu nelze vyřešit konflikty.

[Jakub Lucký]

problémy zacyklených balíčků řeší aptitude poměrně slušně (resp: nabídne alternativy a jedna je obvykle ta dobrá)

[haha]

tohle především vůbec nesouvisí s RPM nebo DPKG. To je snad věc dependency solveru.

[Jakub Lucký]

To nejde popřít...

[podlesh]

Jistě, moje pointa byla že to hlavně závisí na tom jaké ty balíčky jsou a zda se při jejich tvorbě dává dostatečný pozor.

[podlesh]

To právě zas tak moc ne, často je jediným řešením úplné odstranění některých balíčků (což může být OK, pokud je to nepoužívaná ptákovinka z gnome, nebo zásadní pokud je to ghostscript).

[Jakub Lucký]

No, tak uživatel se má podívat, co mu ten aptitude nabízí... Kdo se nedívá a dává zběsilé Yes, ten ať si nainstaluje Windows, tam je to norma...

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.)

[podlesh]

To je jak u blbejch... nabízí mi kompletní odstranění gnome.

To je tedy ten ideální případ, kdy aptitude alespoň funguje a můžu to řešit přes aptitude install/remove.

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 --force

Celkově bych to zhodnotil, že před deseti lety nic takového nebylo, 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.

[haha]

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 --force

Př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..

[podlesh]

No, pokud jsou to špatné závislosti, tak žádná jednoduchá rada není - jen prohlédnout ty závislosti a ručně instalovat/odstraňovat balíčky než se to dostane do stavu kdy 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ě).

[Jakub Lucký]

Pokud je, tak jsou balíčkáři dementi a reportujte to jako bug... gnome-session-bin má mít Provide: gnome-session

[fraxinus]

> nevím proč když je to tar

Asi preto ze to nie je tar ale ar

ar x foo.deb

[disorder]

dobre kydy, pripravujes sa na vstup do politiky?

[Käyttäjä 11133]

Na druhou stranu je nutné uznat, že není RPM jako RPM a takové SUSE RPM, Mandriva RPM a RH RPM se docela zásadně liší Což mě docela štve.

[Michal Kubeček]

Co začali v SuSE používat LZMA místo bzip2, tak je to i verzi od verze… :-(

[thingie]

Kde je v tom problém? Nové balíčky s LZMA payload by stejně do starého systému kde to RPM ještě neumí moc nešly, i kdyby tenhle dílčí problém nebyl.

[Michal Kubeček]

Ono bohužel není jen jedno LZMA, ale od chvíle, co přešli na LZMA, má každá verze distribuce LZMA, které je nekompatibilní s tím předchozím LZMA. Teď naposledy jsem dokonce z 11.3 M2 a delta iso nedokázal vyrobit 11.3 M3 ani za pomoci applydeltaiso a librpm z Factory...

[thingie]

To jsou betaverze, ne?

[Michal Kubeček]

Jsou, ale ten formát pak bude samozřejmě nekompatibilní i v ostré. Jediné štěstí je, že jsou přenositelná aspoň source RPM a že build nějak pozná, jakou verzi formátu má použít, když builduje pro starší verzi distribuce.

[thingie]

No tak že ze staré verze člověk nevybildí správný balíček pro novou, to by mě dvakrát nepohoršilo, to ostatně stejně tak, pokud si jí celou nenatáhne do chrootu. Z nové na starší by samozřejmě nějaká kompatibilita být měla, žejo. Ale prostě na tom nevidím tragedii :)

[Michal Kubeček]

Pokud chce mít člověk na svém desktopu poslední verzi a na serverech ne, tak ocení možnost buildit balíčky pro starší. Naštěstí si s tím build poradí, jinak by to byl docela průšvih (asi bych si na to musel udělat virtuály).

[thingie]

No, já nevím co a jak v suse tohle řeší, ale stejně je třeba nějaký chroot aspoň, nebo tak něco, když člověk dělá balíček pro jiné systémy, jinak je to rizoto.

[Aleš Kapica]

Už pan vindicator pochopil co je na RPM blbě?

[thingie]

To by mě asi dost zajímalo jak s tímhle vláknem jako souvisí.

[Michal Kubeček]

A ono je na něm něco blbě?

[Käyttäjä 11133]

Co je na něm blbě? Že když chceš dobrej balíček pro jinou verzi distribuce je nejstažší toho dosáhnout chrootem? To snad i v debianu, ne? Nebo budeš na lennym dělat balíky pro sarge, nebo naopak? Bez chrootu? Linkovat proti jiným verzím distribuce? :)

[thingie]

Nějakou formu chrootu nebo podobné izolace chcete použít i když buildujete pro stejnou verzi. Vlastně ho chcete použít úplně vždycky, protože chcete buildit na čistém systému, a mít na něm přesně to samé z balíků co bude jinde.

[Michal Kubeček]

Vždyť to píšu celou dobu: řeší to build.

[thingie]

To sem pochopil, že to něco řeší, ale nějak mi to nešlo spolu s těmi nářky na to, že to tak je, kdyby to něco řešilo, tak je to přece fuk, ne?

[Michal Kubeček]

Otázka je, pro jak široký rejstřík distribucí to řeší a řešit bude. Teď jsem měl třeba v 11.2 problémy s výrobou RPM pro 11.1 (build nějak nepoznal, který definiční soubor má použít, a muselo se mu to říct ručně).

[danaketh]

Zajímavé - .deb v MC normálně otevřu. A apt, potažmo aptitude jsou super. Ale jinak nevím jaký je rozdíl mezi RPM a DEB, protože se na ně dívám jako prostý uživatel, takže je to něco jako EXE vs MSI instalátor :)

O RPM-hell jsem nikdy neslyšel a to jsem Debianista :) Jestli to nakonec není jen nějaká legenda mezi RPMkáři o Debianistech :)

A že někdo hysterčí? Hádám, že ze strany RPMkářů by to bylo stejné, kdyby místo RPM použili DEB. Někdo holt trpí potřebou za každou cenu sdělovat světu, že právě jeho OS/progam/packaging tool/whatever je nejlepší. A na internetu to platí dvojnásob :)

[Jirkus]

Taky v každé verzi Ubuntu pomocí MC deb otevřu bez problémů. Kde jste na tento poznatek přišel?

[chrono]

Skús distribúciu, ktorá nepoužíva Debian balíky (takže nebudeš mať dpkg-deb a podobné nástroje) a prestane ti to fungovať. ;)

[Jezekus]

Používam RH RPM distra a deb i rpm otevřu naprosto bez problémů na čisté instalaci.

[chrono]

Mám neupravovaný Midnight Commander a deb balíček v ňom síce otvorím, ale je prázdny a pri otváraní sa vypíše že chýba dpkg a dpkg-deb.

[danaketh]

Mám Debian a nejdou mi otevírat RPM. Čím to tak asi bude? :)

Já měl dodneška za to, že systém volí při pokusu o otevření souboru takovou aplikaci, která je s tímto typem asociovaná (podle .whatever). A pokud systém neví, že .deb je jen ar, tak s ním těžko něco provede. Klidně mě opravte pokud se pletu a žiju v nevědomosti ale připadá mi logické, že když systém/aplikace nezná typ souboru, tak s ním ani nemůže pracovat.

[chrono]

A ja som tvrdil niečo iné? To, že Debian (a podobných distribúciách) .deb balíky v Midnight Commander fungujú nie je prekvapujúce a neznamená to, že to musí fungovať vždy a všade. ;)

[Jakub Lucký]

Ty kráso, to je slušná snůška volovin...

[CET]

Ja osobne si pod RPM dependency hell predstavim dobu, kdyz jsem na RH6 a 7 stahnul balicek RPM, chtel nainstalovat, ale on potreboval dalsi dva balicky. Tak jsem dotahal a pri instalaci to chtelo dalsi sbirku balicku, takze znovu tahat. Nekdy to bylo dost umorne, takhle natahat vsechny balicky a nejhorsi pak bylo, kdyz nejaky balicek z poslednich chtel nejakou jinou verzi neceho, co uz v systemu bylo s jinou verzi (ale to bylo spis jenom u mixu ruznych verzi distra). V tej dobe jsem neznal zadnej program ala yum, ale pokud se nepletu, tak v debianu byl apt-get od zacatku.

Rozdil DEB x RPM zrejme moc velkej neni, apt-get a yum zrejme taky ne, ikdyz osobne se mi vic libi apt-get, protoze yum se mi zda dost pomalejsi. Taky tvorba DEB se mi zda vic promakana, se vsema utilitama a standardnejsima nastrojema (make pro kompilaci a pripravu balicku), nez spec file. Ale mozna uz ma spec file taky spoustu vymozenosti.

[rudiik]

Osobne sem mel tu cest pouzivat jak RPM tak DEB. Pokud chcete vyuzivat jen balicky dane distribuce+verze, nejspis rozdil nepoznate. Nicmene z vlastni zkusenosti musim rict, ze backportovat novejsi balicek (src.rpm) na starsi system - treba jen o verzi zpet byl casto problem. Nedej boze pouzit src.rpm pro jinou disribuci, to uz bylo vubec hardcore a cas od casu sem to proste po hodinach kompilovani a reverznimu reseni zavislosti vse zahodil a sel delat neco smysluplnejsiho. Na druhou stranu to same s deb balicky funguje bez problemu a neni ani problem pujcit si zdrojovy balicek treba z Ubuntu do Debiana. A jeste k nastrojum, opravdu nelze zrovnavat yum a aptitude. Jeste tak mozna smart, ale yum vazne ne...

[pavlix]

Používal jsem RPM i DEB a související nástroje. Nemůžu říct, že by jeden z těch systémů byl ve všem lepší než druhý.

Takže jakákoli histerie z kterékoli strany je neopodstatněná.