În acest articol voi încerca să demonstrez aceleași zăpadă, care oferă o originalitate unică distribuției lui Archlinux. - sistemul de gestionare a pachetelor.
Pacman - baza de gestionare a pachetelor
Archlinux - nu este în plin sens al distribuției cuvântului bazat pe sursă, cum ar fi Gentoo sau, mai ales, Linux de la Scratch. Pentru forma de bază a distribuției sale este încă sub forma unui set de pachete precompilate. Aceste pachete arata ca arhivele obisnuite * tar.gz:
La o examinare mai detaliată, se pare că pachetele Archlinux sunt similare cu cele de tip tarballs, nu numai în aspect, ci și în caracter. le Format - este simplu la extrem, acest lucru este gudron pur za- „ennoe lemn, comprimat gzip“ th, nu conține niciun script de instalare, și, în general, nici o informație meta: doar binar executabil în sine (fișierele binare), destinate a fi plasate în directorul / usr / bin (cu excepția acelor programe care sunt în mod rezonabil să fie în / bin. / sbin sau / usr / sbin), urmat în cazul în care este necesar configurările (pentru directorul / usr / etc) și biblioteci (pentru / usr / lib), precum și om-documentație .
La fel ca și strămoșul său CRUX, Arch recunoaște numai Auntu Manyu, informațiile și alte documente din pachete sunt curățate.
Instrumentul pentru gestionarea acestor pachete pur construite este de asemenea foarte simplu și se numește pacman (din managerul de pachete, trebuie să credeți). Formatul apelului său este după cum urmează:
Indicarea acțiunii este obligatorie, opțiunile, în conformitate cu numele - opțional.
Acțiunile furnizate de comanda pacman. următoarele:
- -A. sau - add - adăugarea (ex. Instalarea) pachetului în sistem;
- -U. -upgrade. și -F. --freshen. - actualizarea pachetului; diferența dintre ele este aceea că în al doilea caz este actualizat numai pachetul instalat anterior (prin intermediul lui -A), în primul - instalarea este efectuată și în absența acesteia;
- -S. - sync. - sincronizarea pachetelor instalate local cu depozitul de distribuție (ftp.archlinux.org) sau cu oglinzile sale;
- -R. -remove. - ștergeți un pachet care rulează fără avertismente, împreună cu toate fișierele de configurare și alte facilități (cu excepția, desigur, configurațiile utilizatorilor din directorul $ HOME);
- -Q. - căutare. - solicitați informații despre pachetul instalat sau neinstalat;
- -V. - versiunea. - ieșirea din numărul versiunii pacman. informații despre drepturile de autor și licențe.
Ca argumente pentru comanda pacman sub acțiunea -A. -U și -F ar trebui să apară numele complete ale fișierelor pachet, formularul - pkg_name-version-release.pkg.tar.gz. Dacă pachetul se află într-unul din locurile destinate acestui lucru (voi vorbi mai târziu despre el), atunci este suficient formularul dat, altfel se va cere calea completă. Într-o singură linie, puteți lista mai multe pachete pentru o instalare sau actualizare unică. Acțiuni -Q. -S și -R necesită numai numele pachetului, fără alte atribute.
Există încă o acțiune - -h. sau --help. (atenție - numai ea și într-o formă concisă este dată în litere mici); - rezultatul unei scurte referințe, și anume, o listă de acțiuni. Dacă oricare dintre ele este atașat acțiunii -h. puteți obține informații mai detaliate despre opțiunile care pot însoți această acțiune. Deci, echipa
oferă o listă cu toate opțiunile disponibile atunci când acțiunea este adusă:
Opțiunile de comandă pacman sunt destul de numeroase, care sunt compensate de obligația lor obișnuită. Important poate fi -d. --nodeps. anularea controlului de dependență și -f. --force. - instalarea forțată a pachetului, precum și -r. --root. . Umolchalnyh de prescriere diferit de directorul sursă (și este sistemul de fișiere rădăcină) și necesită, desigur, specificați calea (de exemplu, / usr / local sau / opt Vreau să menționez opțiunea -c --cascade deoarece utilizarea ei nu necesită o îngrijire specială ..: prescrie o ștergere recursivă nu numai a pachetului specificat, ci și a tuturor dependențelor conexe. Trebuie să rețineți că opțiunile, spre deosebire de acțiuni, sunt date într-o formă concisă doar cu majuscule.
În cele din urmă, cea mai interesantă opțiune este -u. --sysupgrade. Folosite împreună în acțiuni -U sau, chiar mai bine, -S. oferă o actualizare completă a întregului sistem:
Evident, în acest caz, trebuie să vă conectați la Web pentru sincronizarea cu arhivele Archlinux.
Pentru cunoașterea altor opțiuni este oferit să se adreseze mătușii pacman.
Configurarea pacman
Mai sus, am menționat ocazional că, pentru a simplifica instalarea pachetelor, acestea ar trebui plasate în locul potrivit. Și acest lucru este determinat în fișierul de configurare pacman - /etc/pacman.conf.
Ca orice altceva, Archlinux, acest fișier este foarte simplu și constă din două secțiuni - setările generale pentru instalarea pachetelor și lista de depozite ale acestora. Setările generale includ:
care determină lista de pachete care nu sunt afectate de actualizarea totală prin intermediul pacman -Su;
Un fișier care conține o listă de fișiere care nu ar trebui suprascrise pentru instalări sau actualizări de pachete (inclusiv cu o actualizare completă); În mod implicit, aici, cu excepția celor specificate, sunt afișate toate configurațiile de bază de sistem de tip etc / fstab. etc / rc.conf. etc / rc.local. etc .;
calea spre baza de date a pachetelor (în mod implicit - / var / lib / pacman);
dezactivarea modului pasiv de conectare ftp (în mod implicit el este - și acest lucru, tovarăși, este corect în majoritatea cazurilor).
Lista de depozituri a arhivei specifică principalul server ftp al proiectului
și toate oglinzile sale. Listele pot fi setate separat pentru ramura curentă, stabile și includ depozite de pachete neoficiale. În final, puteți specifica și un depozit local de pachete, de exemplu:
Se găsește pachetul într-unul din depozitele listate în /etc/pacman.conf. elimină necesitatea de a specifica calea completă la fișierul pachet, după cum sa discutat mai devreme. Este clar că instalarea pachetului de pe serverul ftp necesită o conexiune la rețea. Depozitul local, unde puteți plasa pachetele descărcate în avans, elimină această nevoie.
Problema de dependență
Am menționat deja în notă despre instalarea programului Archlinux. că instalarea de pachete este fantastic de rapid. Aceasta, în general, este de înțeles: deoarece pacman despachetează pur și simplu arhiva pachetelor și scrie componentele precompilate unde ar trebui să meargă. Deoarece nu există meta informație în pachet, nu există nici o urmă a dependențelor.
Cu toate acestea, există un control al dependenței în sistemul de gestionare a pachetelor Archlinux. Această funcție este atribuită unei baze de date externe (relativ la fiecare pachet) din directorul / var / lib / pacman /. Acesta include două subdirectoare - / var / lib / pacman / current / și / var / lib / pacman / local. În primul - baza tuturor pachetelor acoperite de distribuția Arch Linux (sau, mai mult, partea oficială). Este format din directoare formă pkg-ver-rel (de exemplu, bash-2.05b-6 - exemplele prezentate mai jos se referă la acel pachet), fiecare dintre care are două fișiere: desc - scurtă descriere a pachetului în formă de
și depinde - lista de pachete cu care aceasta este legată de dependențe și, eventual, și pachetele în conflict:
În directorul / var / lib / pacman / local /. după cum sugerează și numele, conține baza de date a pachetelor instalate pe această mașină. Se formează în același mod ca / var / lib / pacman / current /. însă în catalogul fiecărui pachet există deja trei fișiere: desc. depinde și fișierele.
Descrierea pachetului din fișierul desc include, pe lângă informațiile scurte (asemănătoare cu descrierea curentă), și datele de construire și instalare a pachetului, numele colectorului (pentru partea oficială, este arhlinux generalizat) și dimensiunea totală:
În fișierul depinzător. cu excepția listei de pachete de pe care depinde, de asemenea, lista pachetelor care depind de ea:
În cele din urmă, fișierele reprezintă doar o listă a tuturor componentelor pachetului, indicând căile prin care sunt plasate în timpul instalării:
În cazurile necesare, puteți găsi imediat o listă de fișiere modificate când pachetul a fost instalat (în primul rând acest lucru se aplică configurațiilor de sistem), indicând sumele de control inițiale:
Această informație va fi necesară atunci când scoateți pachetul cu comanda pacman -R - pentru a restabili configurația curată a sistemului (datorită faptului că pacman este capabil să "curețe" dezinstalarea pachetelor).
Din structura pachetului de bază este ușor de înțeles dependențelor de control Principiul ArchLinux: atunci când instalați un program nou pachet pacman primele controale directorul / var / lib / pacman / curent /, în scopul de a identifica dependențele sale, și apoi - directorul / var / lib / pacman / local / pe Subiectul dacă pachetele de la care depind aceste date sunt instalate. Dacă totul este în ordine, pachetul este instalat cu succes. Dacă nu, este afișată o listă cu numele pachetelor care lipsesc (în ordinea în care trebuie instalate) și activitatea pacmanului "și se termină cu un mesaj de eroare. Nici o încercare de a rezolva încălcarea dependențelor nu o face automat, lăsând-o în memoria utilizatorului.
Deci, atunci când instalați un pachet pentru care nu sunt îndeplinite dependențele, utilizatorul, după primirea listei corespunzătoare, trebuie să instaleze toate componentele lipsă pe cont propriu. Și cu fiecare dintre ele, este posibil să se repete istoria - adică o încălcare a dependențelor, care trebuie rezolvată manual.
Un astfel de sistem nu pare foarte convenabil. Deși acest lucru este mult mai bun decât rpm clasic. unde în caz de încălcare a dependențelor se produce ceva asemănător cu lipsa bibliotecii name_req.so.1 - și să calculăm la ce pachet aparține. În Archlinux, ieșirea comenzii pacman arată astfel:
apoi pachetele care lipsesc (împreună cu cele necesare) pot fi ușor instalate cu o singură comandă.
Mâinile versus automatizare - argumente pro și contra
Cu toate acestea, în comparație cu sistemele de gestionare a pachetelor așa-cum ar fi "avansate", cum ar fi apt sau chiar yum. pacman pare foarte primitiv. Cu toate acestea, aceasta este a) nu este așa (deoarece nu este altceva decât o adăugare la ABS) și b) are avantajele sale.
Despre discursul ABS în față, ci pe beneficiile „manual“ abordare PacMan (în CRUX adoptată cu privire la același sistem, și PKG-unelte din Slackware nu este cu mult diferit de ei), înainte de sistemele apt de tip aș dori să vorbesc mai mult, din cauza dovezilor lor incomplete .
Cu toate acestea, ne amintim că există două tipuri de pachete: obligatorii sau grele, și nu obligatorii, ca să spunem așa, "moale". Primul - o realitate obiectivă care definește toate mijloacele de executare: nici un program nu poate fi făcută să funcționeze fără glibc (pentru legarea statică nu vorbim aici), nu-aplicație X nu va funcționa fără Xlib. niciun software KDE nu se va ridica fără Qt și kdelibs.
„Soft“ este în conformitate cu executarea nu este necesară, deoarece permit doar pachetul de unele caracteristici suplimentare, utile, inutile, și chiar sincer dăunătoare - și conceptul de beneficiu și rău aici, sincer subiectiv. Deci, majoritatea constructorilor de link-uri sau mc cred că suportul gpm este o condiție indispensabilă pentru folosirea lor. Pentru mine, utilizarea mouse-ului ca dispozitiv de indicare în aceste aplicații pare unică dăunătoare. Nu vorbesc despre faptul că rezoluția dependențele opționale conduce la componentele sistemului de fișiere aglomera, pe care utilizatorul are de multe ori nici o idee (și nu au dorit).
Deci, în ArchLinux utilizatorului un avertisment că el are nevoie de un pachet are nevoie de ceva și că ceva se poate determina dacă ia fost impusă în conformitate cu referire la numărul de obiective „greu“, cu o experiență minimă (și unele reprezentare a dependențelor) , sau "moale", condiționate de reprezentările subiective ale colectorului de colete. Și în cel de-al doilea caz - alegeți în mod conștient:
- simplitate pentru a fi de acord cu propunerea făcută acestuia (care, cu toate acestea, va duce la aglomerarea sistemului);
- refuză să satisfacă dependențe de opțiunea nodeps (în acest caz, există riscul ca pachetul nu va funcționa corect - cu toate acestea, acest risc nu este prea mare pentru dependența „moale“)
- sau doar scuipați și colectați manual pachetul necesar din surse - numai cu cele cu / fără și activați / dezactivați. de care are nevoie într-adevăr.
Desigur, asamblarea manuală are și dezavantajele sale. Instalate în plus față de programele sistemului pachet nu vor cădea în baza de date. În consecință, dacă mai târziu trebuie să instalați pachete care depind de un astfel de "colecționar de sine" prin sistemul pacman, atunci acesta nu va fi detectat ultima dată.
Cu toate acestea, dacă considerăm Archlinux ca fundamentul construirii propriului nostru sistem, limitându-ne la componentele bazei și colectând totul altfel manual - acest lucru este destul de acceptabil. Dacă vă bazați în continuare pe folosirea mixtă a acesteia - componentele critice sunt colectate manual, restul - sunt instalate din pachetele precompilate - apoi ieșirea rămâne. Din moment ce a folosit baza de date cu Pacman „om, foarte simplu, nimeni nu se oprește pentru a face informații despre«auto-asamblare»pachet manual (deși nu există nici un astfel de mijloace de automatizare a acestui proces este de a injecta Gentoo).
Cu toate acestea, tot ce sa spus despre dependențe se aplică numai în cazul instalării pachetelor din mass-media locală. Și dacă utilizați depozitele de pachete de pe ftp-server-ul proiectului sau din oglinzile sale, acesta nu are puterea. Deoarece, așa cum am menționat deja, o comandă simplă pacman -Su va efectua o actualizare completă a sistemului cu rezoluția tuturor dependențelor
Cu toate acestea, utilizatorul Arch are o altă oportunitate mai interesantă. Și aceasta este utilizarea ABS (Arch Build System), un sistem de construire a pachetelor care va alcătui subiectul următoarei note.