Diferențe în gestionarea pachetelor între Debian și Arch

Folosesc arcul regulat de câteva săptămâni și nu sunt expert în acest subiect, așa că acest răspuns nu este deloc exhaustiv, am remarcat doar câteva puncte despre „flexibilitate / putere”:

• Aceasta este doar o impresie, dar Pacman pare mai modern și mai simplu în design / arhitectură. Cel puțin există mult mai puține instrumente de tratat. Deși nu știu codul sursă apt, mi s-a întâmplat să mă uit la codul libalpm (biblioteca care stă la baza Pacman) pentru a crea un patch foarte simplu și pare curat și ușor de înțeles.

• Este, de asemenea, foarte rapid (datorită optimizării și, de asemenea, probabil, având grijă de câteva lucruri (vezi mai jos)). Ultima versiune (Pacman 3.5, veche de câteva zile) a încercat să îmbunătățească performanța prin reducerea numărului de au implicat fișiere de baze de date.

• În timp ce arch este orientat spre utilizarea pachetelor binare, are și avantaje atunci când construiește pachete de la sursă, cu un sistem de construcție similar porturilor BSD ( ABS).

• Este foarte ușor și rapid să creați pachete, doar câteva linii într-un fișier PKGBUILD și gata, nu este nevoie să vă ocupați de control / reguli / drepturi de autor / changelog / orice ar fi ca în cazul pachetelor Debian. Și în câteva clicuri pe o interfață web pachetul dvs. este partajat cu toată lumea din AUR (Arch User Repository).

Lucruri pe care le primesc în Debian și nu în arch:

• Triggers / h ooks (ceea ce face ca apt să actualizeze memoria cache a iconițelor, mandb-ul sau orice altceva, uitându-se doar la locul unde instalează pachetele, fără a fi nevoie ca pachetul să facă ceva) (se pare că există planuri pentru a pune în aplicare acest lucru).

• debconf (nu e mare lucru și apropo, forțându-mă să fac lucrurile manual mă obligă să știu exact ce se face) și gestionarea corectă a noilor fișiere de configurare (aș dori cel puțin ca Pacman să știe când un fișier de configurare dintr-o nouă versiune de pachet este diferit de cel instalat, deoarece a fost modificat în noua versiune sau pentru că l-am modificat local).

• semnarea pachetului (se pare că „s-a lucrat la ).

Pentru că arcul este ușor, singurul motiv real este că vine cu câteva pachete instalate în mod implicit și sunteți încurajat să adăugați doar ceea ce aveți nevoie, deci probabil că nu instalați în mod implicit dependențe opționale este incitarea utilizatorilor să instaleze pentru a evita umflarea .

Comentarii

• Nu pot ‘ să analizez acest lucru: dar pot face fără ea și apropo să știu ce fac mai bine . Există, de asemenea, o greșeală de scris în ultima propoziție.
• În ce limbă este scris managerul de pachete pacman? Are funcționalități de gestionare a pachetelor la nivel scăzut și la nivel înalt, asemănătoare cu dpkg / apt și, dacă da, cum se numesc acestea? Am vrut să spun ” acest lucru nu este mare lucru pentru mine să nu am această funcționalitate (debconf) și forțându-mă să fac lucrurile manual mă obligă să știu exact ce se face „.
• @Faheem Mitha: Pacman este scris în C și este un frontend către libalpm, care gestionează atât ” înalt -level ” și ” nivel scăzut ” gestionarea pachetelor.
• @zanko: Nici ‘ nu vorbesc nativ. Tot ce am vrut să faceți este să clarificați propoziția și nu într-un comentariu, ci pe post în sine. BTW, tipul pe care l-am menționat este opțional . Aș putea edita eu însumi postarea, dar m-am gândit că la fel de bine o puteți remedia împreună cu partea de clarificare.

Mi-am început călătoria pe Linux cu Ubuntu lucid și în prezent folosesc Arch.Am scris o mână de pachete Arch și voi spune că este mult mai ușor decât să scriu pachete Debian. Dar aș vrea să subliniez @gentledevil că Arch are un sistem de cârlige pentru pachete, cunoscut sub numele de install file.

Practic, se numește ${pkgname}.install și conține câteva funcții pentru pre / post instalare / eliminare / actualizare; plasați doar actualizările de font-cache în asta și așa mai departe și funcționează cam la fel ca și cârligele Debian.

De asemenea, observ că ați menționat „fixarea” unei aplicații folosind instrumente de gestionare a pachetelor debian; pacman-ul Arch are acel built-in de asemenea, /etc/pacman.conf acceptă o serie de setări, inclusiv IgnorePkg =, care va împiedica actualizările la orice pachet listat după egal (delimitat de spațiu) )

Comentarii

• De asemenea, deși nu este un pachet repo, puteți utiliza împachetatorul powerpill pentru ca pacman să aibă descărcări paralele de mai multe pachete, deci în loc de pacman -S libfoo libbar libbaz descărcarea fiecărui pachet unul după altul În schimb, ar descărca toate cele trei simultan, crescând foarte mult viteza de actualizare pentru conexiuni mai bune.

Înainte de I mergeți prea departe, studiați Cronologia pictorială Linux

Pentru a înțelege diferențele din Managerii de pachete, trebuie să înțelegeți filosofiile sistemului de operare ” este ilustrat mai sus

Trei părinți principali

1. Redhat, acum Fedora – Manager pachete – RPM, prescurtare pentru Redhat Package Manager, linie de comandă rpm
2. Slackware – Manager de pachete – tgz, fișiere comprimate obișnuite. Deși acestea sunt doar fișiere comprimate, acestea au fost construite de Slackware în amonte și plasate într-un depozit, uneori denumit port
3. Debian – DEB, scurt pentru Debian, instrumentul pentru linia de comandă este Aptitude or Apt

Acești părinți sunt mame și tați pentru majoritatea distribuțiilor pe care le cunoaștem astăzi. Ideea / conceptul unui sistem de gestionare a pachetelor a fost derivat sau împărtășit în unele formă sau modă. Indiferent, toți acești părinți sunt distribuitori binari, ceea ce înseamnă că un program este ambalat și decis de o terță parte, apoi stocat într-un depozit și consumat sau instalat de baza de utilizatori.

3 Părinți minori

1. Linux From Scratch – Bazat pe sursă, fără manager de pachete.
2. Gentoo – Derivat din Linux din Scratch . Această distribuție este în esență Linux de la Scratch plus un manager de pachete, numit Portage / emerge
3. SourceMage – Vrăjitorie Manager de pachete

Acești părinți sunt minori deoarece baza lor de utilizatoritranzacționează viteza și ușurința instalării cu putere și ușurință în configurare. Fiecare pachet este descărcat și compilat de la zero, folosind variabile și fișiere de configurare.

Bridge

Arch a fost creat ca o punte între o distribuție binară, ca unul dintre cei 3 părinți principali, și o distribuție bazată pe sursă, ca unul dintre cei 3 părinți minori. Ca atare, primește statutul de părinte în cronologie, deoarece niciun alt părinte nu a furnizat această funcționalitate. Pacman are flexibilitatea de a permite utilizatorului să instaleze un pachet binar dintr-un depozit oficial sau un pachet personalizat, utilizând sistemul Arch Build. Acest concept oferă un echilibru între puterea pe care o oferă părinții minori cu ușurința de instalare pe care o oferă părinții majori.

În opinia mea, nu managerul de pachete arată puterea unui , deoarece toți administratorii de pachete îndeplinesc aceeași sarcină, care este de a gestiona și menține un sistem sănătos. Ca atare, sistemul pe care îl utilizați ar trebui să fie determinat de factori precum:

• Nivel utilizator: cineva nou pentru linux ar trebui să înceapă cu un părinte major, în timp ce cineva care este competent din punct de vedere tehnic va găsi un echilibru.
• Ce doriți să faceți cu sistemul dvs.: Rularea unui server LAMP cu utilizatori atașați este total diferită decât rularea unui computer desktop pentru navigarea pe web și citirea e-mailurilor.
• Nivel de confort: nivelul utilizatorului nu rezistă, dacă sunteți priceput din punct de vedere tehnic, dar nu doriți să petreceți un weekend compunând un sistem, veți alege un părinte major, indiferent dacă toată lumea pe care o cunoașteți alege altceva.

Comentarii

• Acest lucru este mai folosit pe geneaologia distribuțiilor, mai degrabă decât pe o comparație a instrumentelor de gestionare a pachetelor Pacman și Debian ‘ …
• @jasonwryan That ‘ este punctul, deoarece toți managerii de pachete îndeplinesc aceeași sarcină, adică emerge packagename este același lucru cu sudo apt-get install packagename.
• La acel nivel, da; dar asta pierde în întregime scopul întrebării, adică ce diferențiază pacman de {apt, aptitude}.
• @jasonwryan Am răspuns că în secțiunea The Bridge. În afară de asta, nu există nicio diferență. Singurele diferențe sunt semantice, adică o comandă versus alta.Dacă PO caută diferențe semantice, există un manual pentru asta.

Acesta este nu înseamnă un răspuns complet sau exhaustiv – afișele din fața mea au dat deja câteva puncte foarte bune, aș vrea să-mi adaug cei 2 cenți. Un alt lucru – nu m-am obișnuit niciodată cu apt / dpkg. Părea întotdeauna prea complex eu, mă simt foarte confortabil cu yum / rpm.

Pacman este foarte ușor de utilizat, ceea ce este un profesionist și un con – puteți învăța să-l utilizați (construirea pachetelor deoparte) într-o singură după-amiază – folosește în mare parte funcții intuitive și complete de gestionare a pachetelor, dar – și aceasta este una mare, dar – este extrem de inflexibilă.

Dacă proiectanții nu s-au gândit la o caracteristică în prealabil, sunteți înșelat.

Câteva exemple: nu există versiuni native în pacman. Dacă doriți să retrogradați o versiune de pachet – trebuie să descărcați acea versiune de pachet și să utilizați opțiunea -U (upgrade) pentru a instala din fișier. este foarte orientat spre alwa Folosești pachete de ultimă oră pe sistemul tău.

Nu există curățare internă reală a cache-ului / reconstruire completă. Dacă (din cauza unei probleme de rețea) o descărcare a pachetului a fost coruptă, de ex. În timpul -Syu, mesajul de eroare, deși corect, nu va fi de mare folos – nu va identifica pachetul corupt chiar și cu verbozitatea „completă” și depanarea activată , și nici o cantitate de -Syyc nu va curăța cu adevărat memoria cache și va descărca din nou pachetele. Vestea bună este că -Sc vă va anunța unde sunt pachetele descărcate, astfel încât să puteți elimina pur și simplu pe cel jignitor (dacă puteți afla care este) sau pe toate și să reporniți -Syu.

integrarea pacman cu dkms este, de asemenea, oarecum problematică – în timp ce instalam un nou kernel am continuat să am erori de la dkms. Folosind dkms build & & instalarea dkms împotriva noului nucleu a funcționat fără probleme, totuși pacman nu ar oferi nicio informație de ce dkms a eșuat în timpul upgrade kernel (bănuiesc că nu a trecut niciodată calea corectă a noului kernel și lăsați doar dkms să utilizeze kernel-ul implicit (care rulează curent), dar cu o versiune greșită).

O altă anecdotă despre inflexibilitatea acestuia – ca am spus, „obișnuiam să rpm / yum. Dacă am un fișier pe sistemul meu și doresc să știu ce pachet îl deține, pot rula yum provides / path / to / file și pot obține TOATE pachetele care îl pot pune acolo – chiar dacă niciunul dintre ele nu este instalat. Dacă fișierul a fost plasat manual și acum aș dori să instalez un pachet – acesta va redenumi unul nou (adăugați extensia .rpmnew) și permiteți-mi să aleg ce să folosesc.

pacman pur și simplu erorează că un fișier este deja există, dar cu un mesaj de eroare complet irelevant – se plânge de conflicte între proprietarul „adevărat” al fișierului și pachetul „sisteme de fișiere” instalat în prezent, ca și cum ar fi proprietarul aceluiași fișier. De asemenea, este orientat în principal către informații instalate la nivel local – încercarea de a obține informații (cum ar fi listele de fișiere și proprietatea) pachetelor care nu au fost încă instalate este mai puțin intuitivă.

Pur și simplu – nu este la fel de matur ca yum, și, probabil, dpkg, care îi oferă și ușurința de utilizare, este relativă inflexibilitate.

Comentarii

• Pe scurt, fără un răspuns cuprinzător, există o serie de puncte pe care le susțineți, care sunt într-adevăr un produs al unei necunoașteri cu Pacman. De exemplu, pacman -Qo $file vă va spune ce pachet deține $ fișier. De asemenea, întregul dvs. răspuns este un om de paie, deoarece OP a cerut în mod explicit diferențe între Arch și Debian – yum nu are nimic de-a face cu el …
• motiv pentru care am dezvăluit în mod explicit acest fapt la începutul răspunsului meu. în ceea ce privește fișierul -Qo $ – ați încercat vreodată asta pentru un pachet neinstalat încă?
• Nu are rost să-l încercați pentru un pachet neinstalat; există și alte instrumente pentru asta. Și divulgarea nu ‘ nu atenuează faptul că nu ați ‘ t răspuns la întrebarea: a ” comparația ” între yum și pacman nu este la fel ca diferențele dintre Debian ‘ s și Arch ‘ managerii de pachete.
• @jasonwryan Desigur, există un punct. Doar pentru că nu ‘ nu vedeți necesitatea de a afla ce pachet ar putea deține un fișier chiar dacă ‘ nu este încă instalat, nu ‘ t înseamnă că o astfel de nevoie nu există ‘. Acesta era punctul. În ceea ce privește alte instrumente – au nevoie de cunoștințe? pacman este managerul de pachete. În ceea ce privește punctul dvs. principal – s-ar putea să fi citit complet greșit întrebarea, dar am presupus că este vorba despre un PM ușor față de un PM mai complex. Presupun că apt / dpkg este cel puțin la fel de complex ca yum / rpm, în funcție de caracteristică.
• Ideea mea este că răspundeți la o întrebare despre compararea merelor cu portocalele comparând înțelegerea limitată a merelor cu pere. Și da, ați citit complet greșit întrebarea …