A csomagkezelésbeli különbségek a Debian és az Arch között

Csak néhány hét óta használom az arch-ot rendszeresen és nem vagyok szakértő a témában, így ez a válasz korántsem teljes, csak néhány pontot megjegyeztem a “rugalmasságról / erőről”:

• Ez csak egy benyomás, de A pacman modernebbnek és egyszerűbbnek tűnik a tervezésében / felépítésében. Legalább sokkal kevesebb eszközzel kell foglalkozni. Bár nem ismerem az apt forráskódot, véletlenül megnéztem a libalpm kódot (a pacman mögöttes könyvtárát), hogy egy nagyon egyszerű javítást készítsek, és ez tiszta és könnyen érthetőnek tűnik.

• Ez is nagyon gyors (az optimalizálás miatt, és valószínűleg néhány dologgal is törődve (lásd alább)). Az utolsó kiadás (néhány napos pacman 3.5) megpróbálta javítani a teljesítményt azáltal, hogy csökkentette a érintett adatbázis-fájlok.

• Míg az arch a bináris csomagok használatára irányul, előnyei vannak a csomagok forrásból történő építésénél is, a BSD portjaihoz hasonló felépítési rendszerrel ( ABS).

• Nagyon könnyű és gyors csomagokat létrehozni, csak néhány sor a PKGBUILD fájlban, és kész, nem kell foglalkozni a vezérléssel / szabályokkal / szerzői jogokkal / changelog / bármi, mint a Debian csomagokkal. És néhány kattintással egy webes felhasználói felületre a csomagod mindenkivel meg van osztva az AUR-on (Arch felhasználói tárház).

Amit kapok a Debianban és nem az arch-ban:

• Triggers / h ooks (mi az, ami miatt az apt frissíti az ikon gyorsítótárát, a mandb-ját vagy bármi mást csak azzal, hogy megnézi, hová telepíti a fájl a fájlokat, anélkül, hogy a csomagolónak bármit kellene tennie) (úgy tűnik, vannak tervezi ennek megvalósítását).

• debconf (nem nagy ügy, és mellesleg azzal kényszerít, hogy manuálisan tegyek dolgokat, arra kényszerít, hogy tudjam, mi is pontosan történik) és az új konfigurációs fájlok megfelelő kezelése (legalábbis szeretném, ha a pacman megtudná, hogy egy új csomag verziójú konfigurációs fájl eltér-e a telepítetttől, mert az új verzióban megváltoztatták, vagy mert helyben módosítottam).

• csomag aláírása (úgy tűnik, hogy működött ).

Mivel az arch könnyű, az egyetlen valódi ok az, hogy alapértelmezés szerint kevés csomagot tartalmaz, és javasoljuk, hogy adja hozzá mindazt, amire éppen szüksége van, ezért valószínűleg az opcionális függőségek alapértelmezés szerinti telepítése a felhasználókat a telepítésre ösztönzi .

Megjegyzések

• Nem tudom ‘ ezt elemezni: de nélküle is meg tudom csinálni, és mellesleg tudom, mit csinálok jobban . Az utolsó mondatnál elírás is van.
• Milyen nyelven írják a pacman csomagkezelőt? Van-e alacsony és magas szintű csomagkezelő funkciója, hasonlóan a dpkg / apt-hoz, és ha igen, hogyan hívják őket?
• @Tshepang: sajnálom, itt nem angol anyanyelvűek. Arra gondoltam, hogy ” ez nem nagy baj számomra, ha nem rendelkezem ezzel a funkcionalitással (debconf), és azzal, hogy manuálisan kényszerítem a dolgokat, arra kényszerít, hogy tudjam, pontosan mit is csinálnak “.
• @Faheem Mitha: Pacman C-ben van írva, és a libalpm egyik frontendje, amely mindkét ” -et kezeli -level ” és ” alacsony szintű ” csomagkezelés.
• @zanko: Én ‘ sem vagyok anyanyelvű. Annyit szerettem volna, hogy világosabbá tegye a mondatot, és nem kommentben, hanem magában a bejegyzésben. BTW, az általam említett elgépelés opcionális . Magam is szerkeszthettem a bejegyzést, de úgy gondoltam, hogy a pontosító résszel együtt kijavíthatja.

Linuxos utamat az Ubuntu lucid segítségével kezdtem, és jelenleg az Arch-ot használom.Írtam egy maroknyi Arch csomagot, és sokkal könnyebben mondom, mint a Debian csomagok írása. De szeretném felhívni a figyelmét a @gentledevil oldalra, hogy az Arch-nak van egy kampós rendszere a csomagok számára, amelyet install file.

Alapvetően ${pkgname}.install nevű, és tartalmaz néhány funkciót a telepítés előtti / utáni / eltávolítási / frissítési feladatokhoz; csak helyezze el a font-cache frissítéseket ebben és így tovább, és majdnem ugyanúgy működik, mint a Debian horgai.

Emellett azt is észrevettem, hogy megemlítetted egy alkalmazás “rögzítését” a debian csomagkezelő eszközök segítségével; az Arch pacman-jában ez a beépített a /etc/pacman.conf is számos beállítást elfogad, beleértve az IgnorePkg = funkciókat, amelyek megakadályozzák az egyenlő (szóközzel tagolt) után felsorolt csomagok frissítését )

Megjegyzések

• Bár nem repo csomag, használhatja a powerpill csomagolót is a pacman számára, hogy több csomagot töltsön le párhuzamosan, ezért a pacman -S libfoo libbar libbaz helyett minden csomagot egy másik után töltsön le r ehelyett mindhármat egyszerre tölti le, jelentősen növelve a frissítési sebességet a jobb kapcsolatok érdekében.

Mielőtt menj túl messzire, tanulmányozza a képi Linux idővonalat

A csomagkezelők közötti különbségek megértéséhez meg kell értenie az operációs rendszer filozófiáit ” A fenti képen

Három fő szülő

1. Redhat, Most Fedora – Csomagkezelő – RPM, a Redhat Csomagkezelő rövidítése, parancssor rpm
2. Slackware – Csomagkezelő – tgz, közönséges cipzáras fájlok. Habár ezek csak tömörített fájlok, a Slackware által felfelé építették őket, és egy lerakatba helyezték, amelyet néha portnak is neveztek
3. Debian – DEB, rövidítve a Debian-t, ez a parancssori eszköz Aptitude or Apt

Ezek a szülők anyák és apák a ma ismert disztribúciók többségénél. A Csomagkezelő Rendszer ötlete / koncepciója egyesekben levezetésre került vagy megosztották forma vagy divat. Ettől függetlenül mindezek a szülők bináris terjesztők, ami azt jelenti, hogy egy programot egy harmadik fél csomagol és határoz meg, majd tárol egy adattárban, és a felhasználói bázis fogyasztja vagy telepíti.

3 Kiskorú szülők

1. Linux a Scratchtól – Forrásalapú, nincs csomagkezelő.
2. Gentoo – Linuxból származik a Scratchből . Ez a disztribúció lényegében Linux a Scratch-tól, valamint egy csomagkezelő, az úgynevezett Portage / emerge
3. SourceMage – Package Manager Sorcery

Ezek a szülők kisebbek, mert felhasználói bázisukgyorsasággal és egyszerű telepítéssel, energiával és könnyű konfigurálással kereskedik. Minden csomagot a nulláról töltenek le és állítanak össze, változók és konfigurációs fájlok segítségével.

A híd

Az Arch hidaként jött létre egy bináris terjesztés között, például a 3 fő szülő egyikében, és egy forrásalapú disztribúció, mint a 3 kiskorú szülő egyike. Mint ilyen, szülői státuszt kap az idővonalon, mert más szülő nem biztosította ezt a funkciót. A Pacman rugalmasan megengedi, hogy a felhasználó bináris csomagot telepítsen egy hivatalos adattárból, vagy egy egyedi beépített csomagot az Arch Build System segítségével. Ez a koncepció egyensúlyt teremt a kiskorú szülők által biztosított erő és a nagyobb szülők által nyújtott egyszerű telepítés között.

Véleményem szerint nem a csomagkezelő mutatja meg a rendszer, mivel az összes csomagkezelő ugyanazt a feladatot látja el, ami az egészséges rendszer kezelése és fenntartása. Mint ilyen, az Ön által használt rendszert olyan tényezőknek kell meghatározniuk, mint:

• Felhasználói szint: Valaki a linux újdonságának egy nagyobb szülővel kell kezdődnie, míg valaki, aki technikailag jártas, megtalálja az egyensúlyt.
• Mit szeretne tenni a rendszerével: A LAMP szerver futtatása csatolt felhasználókkal teljesen más, mint az asztali PC futtatása. webböngészéshez és e-mail olvasáshoz.
• Kényelmi szint: A felhasználói szint nem bírja, ha technikailag jártas vagy, de nem akarsz egy hétvégét eltölteni egy rendszer összeállításával, akkor választasz egy fő szülőt, függetlenül attól, hogy mindenki ismeri-e valami mást.

Megjegyzések

• Ez inkább a fókusz a disztribúciók geneaológiájára, nem pedig a pacman és a Debian ‘ csomagkezelő eszközök összehasonlítására …
• @jasonwryan That ‘ s a lényeg, mivel az összes csomagkezelő ugyanazt a feladatot látja el, azaz a emerge packagename ugyanaz, mint a sudo apt-get install packagename.
• Ezen a szinten igen; de ez teljesen elmulasztja a kérdés lényegét, vagyis azt, hogy mi különbözteti meg a pacmant az {apt, aptitude} -tól.
• @jasonwryan A Híd részben erre válaszoltam. Ezen kívül nincs különbség. Az egyetlen különbség szemantikai, vagyis az egyik parancs a másikhoz képest.Ha az OP szemantikai különbségeket keres, akkor erre egy kézikönyv tartozik.

Ez az semmiképpen sem teljes vagy kimerítő válasz – az előttem lévő plakátok már nagyon jó pontokat adtak, csak szeretném hozzáadni a 2 centemet. Egy másik dolog – még soha nem szoktam meg az apt / dpkg-t. Mindig túl komplexnek tűnt én, én vagyok a legkényelmesebb a yum / rpm-ben.

A pacman nagyon könnyen használható, ami profi és gyengeség – egyetlen délután alatt megtanulhatod használni (a csomagépítést félretéve). – többnyire intuitív és teljes csomagkezelési funkciókat használ, de – és ez egy nagy, de – rendkívül rugalmatlan.

Ha a tervezők nem gondoltak előre egy szolgáltatásra, akkor elcseszik.

Néhány példa: nincs natív verzió a pacman-ban. Ha le akarja váltani a csomag verzióját – le kell töltenie az adott csomag verzióját, és a fájlból történő telepítéshez az -U (upgrade) opciót kell használnia. nagyon alwa felé irányul élvonalbeli csomagokat használ a rendszerén.

Nincs igazi belső gyorsítótár-tisztítás / teljes újjáépítés. Ha (hálózati probléma miatt) egy csomag letöltése megsérült, pl. -Syu közben, a hibaüzenet ugyan pontos, de nem sok hasznát veszi – még akkor sem fogja pontosan meghatározni a sérült csomagot, ha a “teljes” szóhasználat és a hibakeresés be van kapcsolva , és semmilyen mennyiségű -Syyc nem fogja igazán megtisztítani a gyorsítótárat és újratölteni a csomagokat. A jó hír az, hogy a -Sc tudatja Önnel, hol vannak a letöltött csomagok, így egyszerűen eltávolíthatja a vétkeset (ha megtudja, melyik az), vagy mindegyiket, és indítsa újra a -Syu-t.

a pacman integrációja a dkms-szel szintén némileg problémás – miközben egy új kernelt telepítettem, a dkms-től folyamatosan hibáztam. A dkms build & & dkms install használata az új rendszermag ellen gond nélkül működött, a pacman azonban semmiféle információt nem ajánlott fel arról, hogy a kernel upgrade (gyanítom, hogy soha nem lépte át az új kernel helyes elérési útját, és hagyta, hogy a dkms az alapértelmezett (aktuálisan futó) kernelt használja, de rossz verzióval).

Egy másik anekdota a vele kapcsolatos rugalmatlanságról – mint kijelentette: “Rpm / yumhoz szoktam. Ha van egy fájl a rendszeremen, és szeretném tudni, melyik csomag birtokolja, akkor futtathatom a yum provides / path / to / file fájlt, és megszerezhetem az ÖSSZES csomagot, amelyek oda tudják tenni – még akkor is, ha egyik sincs telepítve. Ha a fájlt manuálisan helyezték el, és most egy csomagot szeretnék telepíteni – akkor átnevezi az újat (hozzáadja az .rpmnew kiterjesztést), és hadd választhassam, hogy mit használjak.

A pacman egyszerűen téved, hogy egy fájl már szerepel létezik, de teljesen irreleváns hibaüzenettel – a “true” fájl tulajdonosa és a jelenleg telepített “filesystems” csomag közötti konfliktusokra panaszkodik, mintha ugyanazon fájl tulajdonosa is lenne. Ez is főleg a helyi telepített információkra irányul – a még telepítetlen csomagok információszerzése (például fájllista és tulajdonjog) kevésbé intuitív.

Egyszerűen fogalmazva – nem annyira kiforrott, mint a yum, és valószínűleg a dpkg, ami a használatának egyszerűségét is szolgálja, viszonylagos rugalmatlanság.

Megjegyzések

• Átfogó nem válaszadás, számos olyan pont felvetődik, amelyeket valóban felvet a pacman ismeretlenségének eredménye. Például a pacman -Qo $file megmondja, hogy mi a csomag tulajdonosa a $ fájlnak. Ezenkívül az egész válaszod szalmaszálú, mivel az OP kifejezetten különbségeket kért Arch és Debian között – yum semmi köze hozzá …
• ezért ezt a tényt kifejezetten közöltem a válaszom elején. ami a -Qo $ fájlt illeti – kipróbáltad már egy még telepítetlen csomagnál?
• Nincs értelme kipróbálni egy nem telepített csomagot; vannak más eszközök is arra. És a nyilvánosságra hozatal nem enyhíti azt a tényt, hogy ‘ nem válaszolt a kérdésre: a ” yum és pacman összehasonlítása ” nem megegyezik a Debian ‘ s és Arch közötti különbségekkel ‘ s csomagkezelők.
• @jasonwryan Természetesen van egy pont. Csak azért, mert nem ‘ nem látja annak szükségességét, hogy kiderítse, melyik csomag birtokolhatja a fájlt, még akkor is, ha ‘ még nincs telepítve, nem ‘ t azt jelenti, hogy ilyen igény nem létezik ‘. Ez volt a lényeg. Ami a többi eszközt illeti – ismeretre van szükségük? pacman a csomagkezelő. Ami a fő szempontot illeti – lehet, hogy teljesen félreértelmeztem a kérdést, de feltételeztem, hogy egy könnyű PM-ről és egy összetettebb PM-ről van szó. Feltételezem, hogy az apt / dpkg legalább annyira összetett, mint a yum / rpm, jellemzően bölcsen.
• Az a lényeg, hogy Ön az alma és a narancs összehasonlításának kérdésére válaszol, összehasonlítva az alma és körte korlátozott megértését. És igen, teljesen félreolvasta a kérdést …