Rozdíly ve správě balíků mezi Debianem a Archem

Arch používám pravidelně už několik týdnů a nejsem žádný odborník na toto téma, takže tato odpověď není v žádném případě vyčerpávající, pouze několik bodů, které jsem si všiml ohledně „flexibility / síly“:

• Toto je jen dojem, ale pacman vypadá ve své konstrukci / architektuře modernější a jednodušší. Přinejmenším je mnohem méně nástrojů, s nimiž je třeba se vypořádat. I když nevím o vhodném zdrojovém kódu, náhodou jsem se podíval na libalpm kód (základní knihovnu pro pacman), abych vytvořil velmi jednoduchou opravu a zdá se být čistý a snadno pochopitelný.

• Je také velmi rychlý (díky optimalizaci a také pravděpodobně kvůli péči o pár věcí (viz níže)). Poslední vydání (několik dní starý pacman 3.5) se snažil zlepšit výkon snížením počtu zapojené databázové soubory.

• I když je arch zaměřen na použití binárních balíčků, má také výhody při vytváření balíků ze zdroje se systémem sestavování podobným jako porty BSD ( ABS).

• Vytváření balíčků je velmi snadné a rychlé, stačí pár řádků v souboru PKGBUILD a je hotovo, není třeba se zabývat kontrolou / pravidly / autorskými právy / changelog / cokoli jako u balíčků Debianu. A za pár kliknutí na webové uživatelské rozhraní je váš balíček sdílen se všemi na AUR (Arch User Repository).

Věci, které dostávám v Debianu a ne v archu:

• Spustí / h ooks (díky čemuž apt aktualizuje mezipaměť ikon, mandb nebo cokoli jiného, pouhým pohledem na to, kde balíček instaluje soubory, aniž by balicí program musel dělat cokoli) (zdá se, že existuje plány na implementaci).

• debconf (nic velkého a mimochodem tím, že mě nutí dělat věci ručně, to mě nutí vědět, co přesně se děje) a správné zacházení s novými konfiguračními soubory (alespoň bych chtěl, aby pacman věděl, kdy se konfigurační soubor v nové verzi balíčku liší od nainstalovaného, protože byl změněn v nové verzi nebo protože jsem jej lokálně upravil).

• podepisování balíků (zdá se, že se na tom pracuje ).

Aby byl oblouk lehký, jediným skutečným důvodem je, že je dodáván s několika nainstalovanými balíčky ve výchozím nastavení a vy jste vyzváni, abyste přidali to, co právě potřebujete, takže pravděpodobně neinstalovat volitelné závislosti ve výchozím nastavení je pobízet uživatele k instalaci vyhnout se .

Komentáře

• Nemohu to ‚ analyzovat: ale obejdu se bez toho a mimochodem vědět, co dělám lépe . V poslední větě je také překlep.
• V jakém jazyce je napsán správce balíčků pacman? Má funkčnost správy balíků na nízké a vysoké úrovni podobnou dpkg / apt, a pokud ano, jak se jim říká?
• @Tshepang: promiňte, zde není rodilý mluvčí angličtiny. Myslel jsem “ to není velký problém, abych neměl tuto funkcionalitu (debconf) a když mě nutím dělat věci ručně, nutí mě to vědět, co přesně se dělá „.
• @Faheem Mitha: Pacman je napsán v jazyce C a je frontendem libalpm, který zvládá obě “ vysoké -level “ a “ nízkoúrovňový “ správa balíčků.
• @zanko: Ani já ‚ nejsem rodilým mluvčím. Všechno, co jsem chtěl, je udělat větu jasnější, a ne v komentáři, ale v samotném příspěvku. BTW, překlep, který jsem zmínil, je nepovinný . Sám jsem mohl upravit příspěvek, ale myslel jsem si, že bys to mohl opravit i společně s vysvětlující částí.

Začal jsem svou cestu Linuxem s Ubuntu lucid a aktuálně používám Arch.„Napsal jsem několik balíčků Arch a řeknu, že je to mnohem jednodušší než psát balíčky Debian. Rád bych však upozornil na @gentledevil , že Arch má systém háčků pro balíčky, známý jako install file.

V zásadě má název ${pkgname}.install a obsahuje několik funkcí pro pre / post instalaci / odstranění / upgrade; stačí umístit aktualizace font-cache v tom a tak dále a funguje to téměř stejně jako v Debianu.

Také jsem si všiml, že jste zmínili „připnutí“ aplikace pomocí nástrojů pro správu balíčků debian; pacman od Archa má tento vestavěný /etc/pacman.conf také přijímá řadu nastavení, včetně IgnorePkg =, která zabrání upgradům na všechny balíčky uvedené za rovnými (oddělené mezerami) )

Komentáře

• I když se nejedná o repo balíček, můžete použít powerpill obálku aby pacman měl paralelní stahování více balíčků, takže místo pacman -S libfoo libbar libbaz stahování každého balíčku jeden po druhém Místo toho by stáhlo všechny tři současně, čímž by se výrazně zvýšila rychlost upgradu pro lepší připojení.

Než jsem jděte příliš daleko, prostudujte Obrázkovou časovou osu Linuxu

Abyste pochopili rozdíly ve správcích balíčků, musíte pochopit filozofii OS “ Na obrázku výše

Tři hlavní rodiče

1. Redhat, nyní Fedora – správce balíčků – RPM, zkratka pro Redhat Package Manager, příkazový řádek rpm
2. Slackware – správce balíčků – tgz, běžné soubory zazipované. Ačkoli se jedná pouze o komprimované soubory, byly vytvořeny společností Slackware proti proudu a umístěny do úložiště, někdy označovaného jako port
3. Debian – DEB, zkratka pro Debian, jeho nástroj příkazového řádku je Aptitude or Apt

Tito rodiče jsou matkami a otci většiny distribucí, které dnes známe. Myšlenka / koncept systému správy balíků byl odvozen nebo sdílen v některých forma nebo móda. Bez ohledu na to jsou všichni tito rodiče binárními distributory, což znamená, že program je zabalen a rozhoduje o něm třetí strana, poté je uložen v úložišti a spotřebován nebo nainstalován uživatelskou základnou.

3 Menší rodiče

1. Linux From Scratch – založený na zdrojích, žádný správce balíčků.
2. Gentoo – odvozeno od Linux ze Scratch . Tato distribuce je v podstatě Linux od společnosti Scratch plus správce balíčků s názvem Portage / emerge
3. SourceMage – balíček správce čarodějnictví

Tito rodiče jsou menší, protože jejich uživatelská základnavyměňuje rychlost a snadnou instalaci s výkonem a snadnou konfigurací. Každý balíček je stažen a zkompilován úplně od začátku pomocí proměnných a konfiguračních souborů.

Most

Arch byl vytvořen jako most mezi binární distribucí, jako jeden ze 3 hlavních rodičů, a distribuce založená na zdrojích, jako je jeden ze 3 nezletilých rodičů. Jako takový obdrží stav jako nadřazený na časové ose, protože tuto funkci neposkytl žádný jiný nadřízený. Pacman má flexibilitu, která umožňuje uživateli nainstalovat binární balíček z oficiálního úložiště nebo vlastní vytvořený balíček pomocí systému Arch Build. Tento koncept poskytuje rovnováhu mezi výkonem, který dávají nezletilí rodiče, se snadnou instalací, kterou dávají hlavní rodiče.

Podle mého názoru to není správce balíčků, který ukazuje sílu systém, protože všichni správci balíčků provádějí stejný úkol, kterým je správa a údržba zdravého systému. Systém, který používáte, by tedy měl být určen faktory, jako jsou:

• Uživatelská úroveň: Někdo novinka v linuxu by měla začít u Major Parent, zatímco někdo technicky zdatný najde rovnováhu.
• Co chcete dělat se svým systémem: Spuštění serveru LAMP s připojenými uživateli je úplně jiné než spuštění stolního počítače pro procházení webu a čtení e-mailů.
• Úroveň pohodlí: Uživatelská úroveň nevydrží, pokud jste technicky zdatní, ale nechcete strávit víkend sestavováním systému, vyberete si významného rodiče, bez ohledu na to, zda si každý, koho znáte, vybere něco jiného.

Komentáře

• Toto je více zaměřeno spíše než srovnání nástrojů pro správu balíků pacman a Debian ‚ …
• @jasonwryan That ‚ jde o to, že všichni správci balíčků plní stejný úkol, tj. emerge packagename je stejný jako sudo apt-get install packagename.
• Na této úrovni ano; ale to zcela postrádá smysl otázky, tj. co odlišuje pacmana od {apt, aptitude}.
• @jasonwryan Odpověděl jsem na to v sekci Most. Kromě toho není žádný rozdíl. Jediné rozdíly jsou sémantické, tj. Jeden příkaz proti druhému.Pokud OP hledá sémantické rozdíly, existuje k tomu manuál.

Toto je tím v žádném případě úplná nebo vyčerpávající odpověď – plakáty přede mnou již dávají velmi dobré body, rád bych přidal své 2 centy. Další věc – na apt / dpkg jsem si nikdy nezvykl. Vždy se to zdálo příliš složité já jsem s yum / rpm opravdu nejpohodlnější.

pacman se velmi snadno používá, což je pro a proti – můžete se ho naučit používat (vytváření balíčků stranou) za jediné odpoledne – používá převážně intuitivní a kompletní funkce správy balíčků, ale – a to je velké, ale – je extrémně nepružné.

Pokud designéři předem nemysleli na nějakou funkci, jste v háji.

Několik příkladů: v pacmanu není nativní verze. Pokud si přejete downgradovat verzi balíčku – musíte si stáhnout konkrétní verzi balíčku a použít možnost -U (upgrade) k instalaci ze souboru. je velmi zaměřen na alwu ve svém systému používáte špičkové balíčky.

Neexistuje žádné skutečné čištění vnitřní mezipaměti / úplné opětovné sestavení. Pokud (kvůli problému se sítí) došlo k poškození stahování balíčku, např. Během -Syu, chybová zpráva, přestože je přesná, nebude příliš užitečná – nezjistí poškozený balíček ani při zapnuté „úplné“ výřečnosti a ladění , a žádné množství -Syyc opravdu nevyčistí mezipaměť a znovu stáhne balíčky. Dobrou zprávou je, že -Sc vám dá vědět, kde jsou stažené balíčky, takže můžete jednoduše odstranit problematický (pokud zjistíte, který z nich je) nebo všechny a restartovat -Syu.

Integrace pacman s dkms je také poněkud problematická – při instalaci nového jádra jsem stále měl chyby z dkms. Použití dkms build & & instalace dkms proti novému jádru fungovala bez problémů, přesto by pacman nenabízel žádné informace, proč dkms selhal upgrade jádra (domnívám se, že nikdy neprošel správnou cestou nového jádra a nechám dkms použít výchozí (aktuálně běžící) jádro, ale se špatnou verzí).

Další anekdota o jeho nepružnosti – jako uvedl, že jsem zvyklý na ot / min. Pokud mám v systému soubor a chtěl bych vědět, který balíček jej vlastní, můžu spustit yum provides / path / to / file a získat VŠECHNY balíčky, které jej tam mohou dát – i když žádný z nich není nainstalován. Pokud byl soubor umístěn ručně a nyní si přeji nainstalovat balíček – přejmenuje se nový (přidejte příponu .rpmnew) a nechám si vybrat, co použít.

pacman jednoduše chyby, že soubor již existuje, ale se zcela nepodstatnou chybovou zprávou – stěžuje si na konflikty mezi vlastníkem souboru „skutečný“ a aktuálně nainstalovaným balíčkem „souborový systém“, jako by byl také vlastníkem stejného souboru. Také je většinou zaměřen na místní nainstalované informace – snaha získat informace (například seznamy souborů a vlastnictví) dosud nenainstalovaných balíčků je méně intuitivní.

Jednoduše řečeno – není to tak vyzrálé jako mňam, a pravděpodobně dpkg, což jí také usnadňuje použití, je relativní nepružnost.

Komentáře

• Krátce po komplexním neodpovědí, existuje řada bodů, které vznesete a které jsou skutečně produktem neznámosti s pacmanem. Například pacman -Qo $file vám řekne, jaký balíček vlastní $ soubor. Celá vaše odpověď je také slaměná, protože OP výslovně požadoval rozdíly mezi Archem a Debian – yum s tím nemá nic společného …
• což je důvod, proč jsem tuto skutečnost výslovně zveřejnil na začátku své odpovědi. pokud jde o soubor -Qo $ – zkusili jste to někdy u balíčku, který ještě není nainstalován?
• Nemá smysl to zkoušet u nenainstalovaného balíčku; k tomu existují další nástroje. A zveřejnění nezmění ‚ t skutečnost, že jste ‚ t neodpověděli na otázku: a “ srovnání “ mezi yum a pacman není stejné jako rozdíly mezi Debian ‚ s a Arch ‚ s správce balíčků.
• @jasonwryan Samozřejmě, že to má smysl. Jen proto, že ‚ nevidíte potřebu zjistit, který balíček může vlastnit soubor, i když ještě ‚ není nainstalován, ‚ to neznamená, že taková potřeba ‚ neexistuje. O to šlo. Pokud jde o další nástroje – je třeba je znát? pacman je správce balíčků. Pokud jde o váš hlavní bod – mohl jsem tuto otázku úplně chybně přečíst, ale předpokládal jsem, že jde o lehký PM vs. složitější PM. Předpokládám, že apt / dpkg bude přinejmenším stejně složitý jako yum / rpm, funkce moudře.
• Jde mi o to, že odpovídáte na otázku týkající se srovnání jablek s pomeranči porovnáním omezeného chápání jablek s hruškami. A ano, zcela jste otázku špatně přečetli …