Rozdíl mezi deb a rpm distry

[fedora]

Je to v navaznosti na http://forum.root.cz/index.php?topic=11449.msg138471#msg138471.
Jsem velky fanda Fedory - urcite neni dokonala, ale temer ano
Nebojte se vychvalit, proc treba zase vy nedate dopustit na Ubuntu (nebo jine Debiani distro), rad se poucim a urcite nejen ja.
Dik. Slusne prosim

[Reklama]

[Daniel Kozak]

Tak ono nejde ani tak o to jestli je distribuce zalozena na rpm nebo deb. Osobne mam zkusenosti jak s rpm, deb, archlinux balicky. A ve vsech pripadech je to vlastne velmi podobne. Asi nejvice mi vyhovuji archlinux balicky, a to zejmena kvuli jejich snadnemu tvoreni. Mam zkusenosti i s tvorenim balicku pro rpm a deb, ale nikdy mi to neprislo tak prime a snadne jako u archu.

S pohledu dister, mam asi nejlepsi zkusenosti s centos a debianem na server (ani s jednim jsem nenarazil na vetsi problemy). Zkusenosti na desktopu jsou jak u ubuntu tak fedory velmi smisene. Ubunti LTS jsou jakztak vpohode. Ale osobne neda dopustit na Archa.

[neruda]

me se s deb pracuje o hodne hur nez s rpm nebo s PKGBUILD (Arch), ale v distribucich dava prednost debian odnozim.

Dlouhodobe jedu na Archu, ale sirsi rodinne instaluju Ubuntu a jestli nekdy budu muset preinstalovavat, tak na tom Ubuntu asi skoncim taky, at je to unifikovany ...

Fedore jsem nikdy nejak neprisel na chut, to uz radsi CentOS pro nejake stabilni prostredi (i desktop), nicmene to proste neni muj salek ...

[karel]

Používám Debian, zatím se mi ho nepodařilo zničit do nepoužitelného stavu.
Počáteční vzhled je strašný, flexibilita a podpora úžasná, tedy mimo komerčních ovladačů -> CentOS (rpm) je lépe podporován.

[podlesh]

me se s deb pracuje o hodne hur nez s rpm nebo s PKGBUILD (Arch), ale v distribucich dava prednost debian odnozim.

Já jsem sice vždy preferoval debian, ale teprve když jsem začal balíčky vyrábět tak jsem začal rpm (a hlavně redhat/centos) vyloženě nesnášet.

Vyrobit deb je řádově jednodušší než vyrobit rpm. Když už nic jiného, tak ho můžu vyrobit jednoduchým zabalením souborů, bež šíleného psaní scriptů na scripty co přesouvají soubory tříkrát po disku sem a tam (radost pokud jsou to stovky MB) - stačí jen tar, ar a xz. Při použití debhelperu už je to složitější, ale pořád mi to přijde jednodušší a lépe zdokumentované než u rpm. A hlavně lépe predikovatelné, protože u rpmbuild vlastně nedokážu předem říct co bude dělat.

Pro ty co nevědí na co narážím, tak historka k táborovému ohni: rpmbuild na redhat instalaci automaticky spouští různé pluginy které má nainstalované. Aniž by se o nich něco psalo ve specfile - naopak, ve specfile je nutné je vypnout, což je samozřejmě zcela nedokumentované (ale dá se vygooglit v supportních maillistech a bugzile). Konkrétní přiklady dvou obzvláště vypečených:

• Java repack: hledá všechny soubory .jar a pokud je najde, tak je rozbalí a zase zabalí (se seřazeným pořadím). Nu dobře, to by tolik ani nevadilo... až na takový detail, že pracovný adresář to má natvrdo jeden, takže pokud se zrovna sejdou dva takové rpmbuild v jeden okamžik, tak si začnou vesele navzájem mazat soubory. A taková situace je na build/CI serveru samozřejmě naprosto normální.
  
• Python comppile: hledá všechny .py soubory a zkompiluje je do .pyc. Nu dobře, proč ne... No protože pak se spouští check který kontroluje přítomnost binárek a ten mi vynadá, že dávám platform-specific binárky do noarch balíku (a zfailuje). No alespoň není nuda.
  

[Reklama]

[TKL]

Asi by se slušelo, abych odpověděl, když už tohle vlákno vzniklo i na základě mé zmínky jinde...

Pro mě je jednou z hlavních výhod deb dister oproti těm založeným na rpm to, že všude najdu apt. Tzn. nemusím si pamatovat, jakého správce balíků používá RedHat a CentOS, jakého SuSe, jakého Mandriva (R.I.P.) atd. O parametrech jednotlivých nemluvě. Ano, můžu všude požít přímo rpm, stejně jako dpkg u deb dister, ale kdo by to krom masochistů nebo speciálních případů dělal...

Další nezanedbatelné plus je geniálně jednoduchý a funkční net install - rovněž společný pro všechna (aspoň myslím, samozřejmě neznám všechna) deb distra. Kdo někdy instaloval např. CentOS pomocí jeho net installu (nejlépe do VMware přes vzdálenou konzoli) ví, o čem mluvím.

Třetí důležitá věc: můžu si ručně upravit jakýkoliv konfigurační soubor a nikomu (míněno žádnému univerzálnímu nastavovači) to nevadí. Opět jeden příklad za všechny - nastavení čehokoliv systémového v SLES. A ty konfiguráky najdu na předpokládatelných místech, to beru jako další nezanedbatelné plus.

Samozřejmě by se dalo mluvit o dalších rozdílech, tyhle tři mi ale připadají jako nejdůležitější. Ostatní mohou (a nemusí) být jen subjektivní pocit nebo nezvyk. Třeba problém s chybějícími balíky při instalaci něčeho nestandardního. Léta se starám o servery s IBM Domino, pár jsem jich sám instaloval. Na SLES nebo CentOS jsem se vždy potýkal s chybějícími knihovnami, když bylo potřeba nějakou nainstalovat z jiného zdroje, narážel jsem na cyklící se problémy se závislostmi. U Debianu se mi to nestalo. Samozřejmě nějaký balík v repozitářích občas chybí, ale když něco stáhnu odjinud, závislosti bývají snadno vyřešeny. Můj pocit je, že deb repa jsou v mnohem konzistentnějším stavu napříč deb distry (tudíž není problém si do Ubuntu přidat repo z Debianu), kdežto rpm repa jsou mnohem více specifická pro každou distribuci.

Takže když to shrnu: můj pocit je, že na Debianu a derivátech mnohem méně narážím na problémy a když už na nějaký narazím, lze ho vyřešit snadněji, než na RedHatu a odvozených. Samozřejmě, vždy může dojít k zapeklitému problému bez ohledu na konkrétní OS. Stejně tak nijak nezpochybňuji stabilitu rpm dister, sám několik serverů s CentOS provozuji a když pominu instalaci a základní nastavení, tak fungují spolehlivě a v podstatě o nich nevím.

[Michal Lenc]

Mě by zajímala jedna věc. Existuje linuxová distribuce, která by netrpěla dependency hell? Tedy, že by neměla sdílené knihovny, ale každá aplikace by si tahala s sebou vlastní sadu knihoven? Našel jsem k tomu nějaké informace, ale nebylo mi to úplně jasné. Dovedu si představit, že by z důvodu úspory místa mohl existovat program nebo script, který by stejné knihovny (třeba na základě MD5 hashe) slinkoval, ale v případě, že by se knihovna změnila nebo upgradovala, tak by je zase rozlinkoval a rozdělil.

[Ondro]

Neviem, ci existuje, skor nie. Preco? Neviem si uz len predstavit  kto by vsetky programy upravoval aby pouzivali staticke kniznice.

Vsetko ma svoje vyhody aj nevyhody. Rovnako je to aj s kniznicami a "svet" si vybral zdielane kniznice.

[Foo]

Zavisi to do toho naco to chcete pouzivat.

• Na bezne desktop distro kde sa len browsuje a pustaju multimedia to je uplne jedno ci rpm+yum alebo dpkg+apt, pretoze sa len instaluju bezne baliky.
• Na serveri v podstate rozhoduje len jedna vec - mame oracle ? Ak ano tak RHEL/CentOS a rpm. Ak oracle nemame, tak radsej deb distro viacmenej len koli tomu, ze ma viac balickov nez rpm distra.
• Som developer - tu sa kedysi dalo zit na rpm distrach a neexistujuce balicky nejak stiahnut cez http://rpm.pbone.net/, najlepsie srpm a tie si buildnut sami. To samozrejme narazalo na to ze potrebujete dalsich XY kniznic ktore vas system nema a binarky nie su a tak dalej hladat a kompilovat...  Pred 2 rokmi som teda na devel presiel na deb distro (Mint + gnome2) a problem chybajucej kniznice ci jej kompilacie som riesil mozno 2-3x ? co je pre mna dost podstatny prinos.

[Ivoszz]

Mě by zajímala jedna věc. Existuje linuxová distribuce, která by netrpěla dependency hell? Tedy, že by neměla sdílené knihovny, ale každá aplikace by si tahala s sebou vlastní sadu knihoven? Našel jsem k tomu nějaké informace, ale nebylo mi to úplně jasné. Dovedu si představit, že by z důvodu úspory místa mohl existovat program nebo script, který by stejné knihovny (třeba na základě MD5 hashe) slinkoval, ale v případě, že by se knihovna změnila nebo upgradovala, tak by je zase rozlinkoval a rozdělil.

docker, libovolná distribuce

[pleca]

Mě by zajímala jedna věc. Existuje linuxová distribuce, která by netrpěla dependency hell? Tedy, že by neměla sdílené knihovny, ale každá aplikace by si tahala s sebou vlastní sadu knihoven? Našel jsem k tomu nějaké informace, ale nebylo mi to úplně jasné. Dovedu si představit, že by z důvodu úspory místa mohl existovat program nebo script, který by stejné knihovny (třeba na základě MD5 hashe) slinkoval, ale v případě, že by se knihovna změnila nebo upgradovala, tak by je zase rozlinkoval a rozdělil.

ja myslim, ze na podobnem principu funguji ubuntu Snappy packages (momentalne asi pouzivane pouze na ubuntu cloud servers), snappy package muze obsahovat vsechny knihovny + soubory, ktere potrebuje http://www.pcworld.com/article/2942267/why-ubuntu-plans-to-replace-traditional-linux-packages-with-something-better.html#tk.rss_all

[TKL]

Mě by zajímala jedna věc. Existuje linuxová distribuce, která by netrpěla dependency hell? Tedy, že by neměla sdílené knihovny, ale každá aplikace by si tahala s sebou vlastní sadu knihoven? Našel jsem k tomu nějaké informace, ale nebylo mi to úplně jasné. Dovedu si představit, že by z důvodu úspory místa mohl existovat program nebo script, který by stejné knihovny (třeba na základě MD5 hashe) slinkoval, ale v případě, že by se knihovna změnila nebo upgradovala, tak by je zase rozlinkoval a rozdělil.

ja myslim, ze na podobnem principu funguji ubuntu Snappy packages (momentalne asi pouzivane pouze na ubuntu cloud servers), snappy package muze obsahovat vsechny knihovny + soubory, ktere potrebuje http://www.pcworld.com/article/2942267/why-ubuntu-plans-to-replace-traditional-linux-packages-with-something-better.html#tk.rss_all

Nebo Mac OS X, i když to je spíše BSD :-)

[JardaP .]

Mě by zajímala jedna věc. Existuje linuxová distribuce, která by netrpěla dependency hell? Tedy, že by neměla sdílené knihovny, ale každá aplikace by si tahala s sebou vlastní sadu knihoven?

Takovych distribuci uz par bylo, jestli se nepletu. Dokonce byla i jedna takova, ktera mela adresarovou strukturu jak Widle, aby z toho useri nebyli tolik na vetvi. Ale vsechny postupne nejak vysumnely do ztracena. Zretelne z nich nikdo nemel zadny orgasmus a tak tu zustavaji distra jako Debian, Red Hat a jim podobne.