Jaké jsou výhody / nevýhody deb vs. rpm?

Mnoho lidí porovnává instalaci softwaru s apt-get to rpm -i, a proto říkejte DEB lépe. To však nemá nic společného s formátem souboru DEB. Skutečné srovnání je dpkg vs rpm a aptitude/apt-* vs zypper/yum.

Z pohledu uživatele není v těchto nástrojích velký rozdíl. Formáty RPM a DEB jsou pouze archivní soubory, k nimž jsou připojena některá metadata. Oba jsou stejně tajemní, mají pevně zakódované instalační cesty (yuck!) A liší se pouze jemnými detaily. Oba dpkg -i a rpm -i nemá způsob, jak zjistit, jak nainstalovat závislosti, s výjimkou případů, kdy jsou uvedeny v příkazovém řádku.

Na vrcholu těchto nástrojů je správa úložišť ve formě apt-... nebo zypper/yum. Tyto nástroje stahují úložiště, sledují všechna metadata a automatizují stahování závislostí. Konečná instalace každého jednotlivého balíčku je předána nástrojům nízké úrovně.

Na dlouhou dobu, apt-get byl vynikající ve zpracování obrovského množství metadat opravdu rychle, zatímco yum by to trvalo věky. RPM také trpěly weby, jako je rpmfind, kde najdete více než 10 nekompatibilních balíčků pro různé distribuce. Apt tento problém pro DEB balíčky úplně skryl, protože všechny balíčky byly nainstalovány ze stejného zdroje.

Podle mého názoru zypper tuto mezeru skutečně uzavřela na apt a není důvod se stydět za použití distribuce založené na RPM v těchto dnech. Stejně tak dobré, ne-li snadnější, je použití služby sestavení openSUSE po ruce pro obrovský index kompatibilních balíků.

Z pohledu správce systému jsem našel několik drobných rozdílů, zejména v sadě nástrojů dpkg/rpm, spíše než ve formátu balíčku.

• dpkg-divert umožňuje, aby váš vlastní soubor nahradil soubor pocházející z balíčku. Může to být záchranář, pokud máte program, který hledá soubor v /usr nebo /lib a nebere /usr/local pro odpověď. Myšlenka byla navržena, ale pokud můžu říct, že nebyla přijata, v otáčkách.

• Když jsem naposledy spravoval systémy založené na otáčkách za minutu (což bylo pravda před lety, možná se situace zlepšila), otáčky za minutu vždy přepsaly upravené konfigurační soubory a přesunuly mé úpravy do *.rpmsave (IIRC). Díky tomu se můj systém mohl alespoň jednou zavést. Dpkg se mě zeptá, co mám dělat, s ponecháním mých přizpůsobení jako výchozí.

• Binární balíček rpm může deklarovat závislosti na souborech spíše než na balíčcích, což umožňuje lepší kontrolu než balíček deb.

• Nelze nainstalovat balíček N rpm verze do systému s verzí N-1 nástrojů pro rpm. To by mohlo platit i pro dpkg, s výjimkou formátu, který se nemění tak často.

• Databáze dpkg se skládá z textových souborů. Databáze rpm je binární. Díky tomu lze databázi dpkg snadno prošetřit a opravit. Na druhou stranu, pokud se nic nepovede, otáčky za minutu mohou být mnohem rychlejší (instalace deb vyžaduje čtení tisíce malých souborů).

• Balíček deb používá standardní formáty (ar, tar, gzip), takže si můžete snadno prohlédnout a ve štípnutí Tweak) deb balíčky. Rpm balíčky nejsou zdaleka tak přátelské.

RPM:

• „Standardizovaný“ (ne, že neexistuje specifikace dluhu)
• Používá se v mnoha různých distribucích (ale balíčky z jedné nemusí nutně fungovat na jiné)
• IIRC umožňuje závislosti na souborech, nejen na balíčcích

DEB:

• Rostoucí popularita
• Umožňuje doporučení a návrhy (možná to umožňuje i novější RPM)

Pravděpodobně důležitější otázkou je spíše správce balíků (dpkg vs. yum vs. aptitude atd.) Než formát balíčku (protože oba jsou srovnatelné).

Jak uvedlo několik respondentů, není to tak moc, že ​​určitý formát balíčku je jasně lepší. Technicky mohou být více či méně srovnatelné. Z mého pohledu spousta rozdílů, a proč lidé dávají přednost jedné před druhou, souvisí s:

• Filozofie originálního designu obalu a cílové skupiny
• Velikost komunity a rozšířením kvalita a bohatost úložišť

Filozofie:

Ve světě Ubuntu/Debian/Mint/... uživatelé očekávají, že nainstalovaný balíček po instalaci „bude fungovat“. To znamená, že během instalace se od balíčků očekává, že se postarají o vše, co je potřeba, aby se zajistilo jejich dobré fungování, mimo jiné včetně:

• nastavení potřebných nebo volitelných cron úloh
• nastavení alternativ/přezdívek
• nastavení spouštěcích/vypínacích skriptů
• včetně všech potřebných konfiguračních souborů s výchozími hodnotami, které dávají smysl
• zachování starých verzí knihoven a přidání správných verzí symbolických odkazů do knihoven (.so) pro zpětnou kompatibilitu
• čistá podpora pro binární soubory s více archy (32 a 64 bitů) na stejném počítači atd.

Ve světě rpm - to byla situace před několika lety, a od té doby se to mohlo zlepšit - zjistil jsem, že musím provést další kroky (např. Chkconfig, umožňující cron úlohy), aby balíčky skutečně fungovaly. To může být v pořádku pro sysadminy nebo lidi, kteří mají znalosti o Unixu, ale to způsobuje, že trpí nováčkové zážitky. Všimněte si, že to není tak, že to samotný formát balíčku RPM brání tomu, aby se to stalo, je to jen to, že mnoho balíčků de-facto není "plně hotovo" z perspektiva nováčka.

Velikost komunity, účast a bohatství repozitářů:

Protože komunita ubuntu/debian/mincovna/... je větší, více lidí se podílí na balení a testování softwaru. Zjistil jsem, že bohatství a kvalita úložišť jsou vynikající. V ubuntu zřídka, pokud vůbec, potřebuji stáhnout zdroj a z něj stavět. Když jsem doma přešel z Red Hat na Ubuntu, typické RHEL repo obsahovalo ~ 3000 balíčků, zatímco Ubuntu + universe + multiverse všechny dostupné přímo z jakéhokoli zrcadla Canon, mělo ~ 30 000 balíčků (zhruba 10x). Většina balíčků, které jsem hledal ve formátu RPM, nebyla snadno dostupná jednoduchým prohledáváním a kliknutím na správce balíčků. Vyžadovali přechod na alternativní repozitáře, prohledat webovou stránku služby rpmfind atd. Ve většině případů, namísto vyřešení problému, se moje instalace přerušila tím, že se neomezilo to, jaké závislosti mohou nebo nemohou být upgradovány správně. Udeřil jsem do fenoménu "pekla závislosti", jak je popsáno výše od Shawn J. Goffa.

Na rozdíl od Ubuntu/Debian jsem zjistil, že téměř nikdy nemusím stavět ze zdroje. Také kvůli:

• Cyklus uvolnění Ubuntu (6 měsíců)
• Existence plně kompatibilních PPA, které fungují mimo pole
• Repozitáře s jediným zdrojem (všechny hostované společností Canonical) nemusí hledat alternativní/doplňkové repozitáře
• Plynulé uživatelské prostředí od spuštění po kliknutí

Nikdy jsem nemusel dělat kompromisy ohledně starších verzí balíčků, na kterých mi záleželo, i když nebyly udržovány oficiálními (kanonickými) vývojáři. Nikdy jsem nemusel opustit svého oblíbeného přátelského správce balíčků GUI, abych provedl pohodlné vyhledávání podle klíčových slov, abych našel a nainstaloval jakýkoli požadovaný balíček. Několikrát jsem na Ubuntu nainstaloval debian (ne Canonical) balíčky a fungovaly dobře, přestože tato kompatibilita není oficiálně zaručena.

Všimněte si, že to nemá za cíl zahájit plamenovou válku, je to jen sdílení mé zkušenosti s používáním obou světů paralelně po několik let (práce vs. domov).

Myslím, že zkreslení nepochází z formátu balíčku, ale z nesrovnalostí, které existovaly v repozitářích RedHat.

Když byla RedHat distribucí (před dny RHEL, Fedora a Fedora Core), lidé se někdy ocitli v "RPM pekle" nebo "pekle závislosti". K tomu došlo, když úložiště skončilo balíčkem, který měl závislosti (obvykle několik vrstev hluboko), které se vzájemně vylučovaly. Nebo by se to stalo, kdyby dva různé balíčky měly dvě vzájemně se vylučující závislosti. To byl problém se stavem úložiště, nikoli s formátem balíčku. "RPM peklo" zanechalo nechutnost pro RPM systémy mezi populací uživatelů Linuxu, kteří se problémem spálili.

Existuje také „filosofický“ rozdíl, kdy v balíčcích Debianu můžete klást otázky, a tím blokovat proces instalace. Špatnou stránkou je, že některé balíčky blokují vaše aktualizace, dokud neodpovíte. Dobrá stránka toho je také, jako filozofický rozdíl, v systémech založených na Debianu, když je balíček nainstalován, je nakonfigurován (ne vždy, jak byste chtěli) a spuštěn. Ne na systémech založených na Redhat, kde musíte vytvořit/kopírovat z/usr/share/doc/* výchozího konfiguračního souboru/šablony.

Jedna věc, která se mi na RPM líbí, je (nedávné?) Přidání delta RPM. To umožňuje snadnější aktualizaci a snižuje potřebnou šířku pásma.

DEB jsou standardní soubory ar (s více standardními archivy uvnitř), RPM jsou "proprietární" binární soubory. Osobně si myslím, že ten první je pohodlnější.

Jen dvě věci, které si mohu vymyslet z hlavy. Oba jsou velmi srovnatelné. Oba mají vynikající nástroje pro balení. Nemyslím si, že existuje tolik zásluh pro jednoho nad druhým nebo naopak.

Balíky Debianu mohou obsahovat instalovaná velikost , ale nemyslím si, že RPM mají ekvivalentní pole. Může být vypočítán na základě souborů obsažených v balíčku, ale nelze se na něj spolehnout ani z důvodu akcí, které lze provést v před/post instalačních skriptech.

Zde je docela dobrý odkaz pro porovnání některých specifických funkcí, které jsou k dispozici pro každý konkrétní formát balení: http://debian-br.sourceforge.net/txt/alien.htm (podle webu server, tento dokument je docela starý: Poslední změna: Ne, 15. října 2000 , takže to nemusí být nejlepší reference.)

Služba OpenSUSE Build Service (OBS) a zypper jsou některé z důvodů, proč dávám přednost RPM před deb z balicího a uživatelského hlediska. Zypper prošel dlouhou cestu a je docela rychlý. OBS, i když dokáže zvládnout debety, je opravdu pěkné, pokud jde o balení rpms pro různé platformy, jako je openSUSE, SLE, RHEL, centos, Fedora, mandriva atd.

Žádná z dalších odpovědí se nedotýká toho, jak tyto tři rozdíly základní mají skutečné důsledky:

1. Soubory deb jsou v podstatě pouze archivy ar obsahující dva komprimované tarbaly
2. Balíky deb a systém dpkg ukládají skripty správce jako samostatné soubory
3. dpkg a rpm během upgradu spusťte skripty správce v jiném pořadí.

Společně tyto rozdíly způsobily mnohem jednodušší pro mě opravit problémy způsobené špatnými balíčky a nechat balíčky chovat se tak, jak je potřebuji, na systémech založených na deb než na Systémy založené na rpm, oba jako správce systému a jako balič.

Z důvodu # 1, pokud potřebuji změnit soubor deb, mohu ho triviálně otevřít, provést jakékoli změny a přebalit jej pomocí standardních nástrojů, které existují ve většině systémů =.

To zahrnuje změnu/přidání/odebrání závislostí nebo souborů balíčku nebo skriptů správců nebo změnu verze nebo názvu balíčku.

Vzhledem k # 2, pokud je problém v "odebrat" skripty nainstalované balíčkem to je již nainstalováno, mohu to triviálně opravit, pomocí standardních nástrojů, které existují v jakémkoli systém.

Kvůli č. 3 mohu některé z těchto oprav provést pouhým uvolněním nové verze mého balíčku, protože během upgradu dpkg spustí skript „předinstalovat“ nové verze balíčku dříve skript „post-remove“ staré verze.

To znamená, že povrchová plocha pro porušení „principu obnovitelnosti“ je v balíčcích deb menší: z nové verze lze získat více chyb v dřívější verzi balíčku.

A protože je modifikace balíčku tak snadná - skutečná režie a znalosti znalostí specifické pro daný balíček jsou malé - je přístupná více lidem a vyžaduje méně času a úsilí pomocí souborů deb.

U balíků Debian existuje velká sada pomocných skriptů, konzistentní příručka s pokyny a alespoň jeden způsob, jak dělat téměř všechno. Závislosti se zpracovávají velmi dobře a lze je definovat ve velmi dobré granularitě. Přestavba balíčků je s balíčky debian velmi snadná a dostupné nástroje jsou dobře podporovány.

Vyhledejte Google

1. rpm duplicitní balíčky
2. dpkg duplicitní balíčky

Přečtěte si stránky, které se vracejí. Velmi říkám, že můžete mít zmatenou RPM databázi s duplicitními balíčky, aniž by k tomu došlo u dpkg.