Portál AbcLinuxu, 2. května 2025 05:33
rpmrebuild, ale používá na to /usr/bin/build
2. Pokud dojde k problému při x86_64 s přeinstalováním půlky systému tak je to prostě na bugzillu.
3. To že v závislostech debianích balíčků by byl menčí bordel kvůli tomu, že by záviseli jen na balíčcích samotných je pěkná hloupost 
Výhoda debianu je v tom, že má policy takové jaké má a tedy, že v jeho repositářích může růst každý balíček a nedochází tam tak k situacím jako například v openSUSE, kdy polovina balíčků roste v Packmanovi, který neumí při změně závislosti libA přebuildit všechny aplikace které na libA závisí. Proto musí aktualizace hlídat balíkáři, kdyby byly ty balíčky součástí distribuce, tak by si to ohlídal autobuild a balíčky by tak byly konzistentní. A ani závislosti jen na balíčcích k ničemu nepomůžou... Mimochodem ono se to automatické registrování závislostí dá vypnout a pak to může být přesně jako v debianu... 
v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.Na druhou stranu možnost souborových závislostí zase zjednodušuje práci vývojáře. Výhoda není tak jednoznačná na jedné ani druhé straně.
Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.
V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.Já jsem četl pravý opak. Sám dělám ale pouze RPM balíčky, takže nemůžu srovnávat.
Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.Ne, žádná taková potřeba neexistuje, to by byla pitomost.
Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.Ony ty nejpoužívanější 32bit balíky mají verzi pro architekturu AMD64. Rozdíl je IMHO v tom, že Debian udělá změnu AMD64->i586 pouze na výslovné přání uživatele. RPM distro tu změnu na výslovné přání neudělá. Výsledek je de-facto stejný, jen mi přijde, že RPM musím kvůli tomu více hlídat pokaždé, když něco instaluju.
ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.To je naopak velmi nedoporučované. Vše v RPM samozřejmě závisí na uživatelském nastavení, žádné takové "absolutní povinné cesty" neexistují.
V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.Nevím, ve vytváření deb balíčků se nevyznám. Nicméně k vytvoření RPM vám stačí jeden .spec soubor (něco jako recept na sestavení) a jeden soubor se zdrojovými kódy (tarball). To mi připadá velmi přehledné.
Je třeba mít na paměti, že množina distribucí používajících RPM je značně heterogenní. DEB balíčky byly donedávna výsostnou doménou Debianu, to spoustu věcí zjednodušuje. K výhodám RPM: co třeba rollbacks ? To se může docela hodit.
22.9.2008 15:35
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
22.9.2008 21:46
belisarivs | skóre: 22
| blog: Psychobláboly
Mne na rpm chybi urovne zavislosti jako v Deb. Cili neco jako - depends, recommends, suggests.Škoda, že máme každý jiné suse :D Software Management/Dependencies
23.9.2008 10:03
belisarivs | skóre: 22
| blog: Psychobláboly
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
22.9.2008 14:22
22.9.2008 14:38
23.9.2008 08:23