Dependency Hell este un anti-model de gestionare a configurației , creșterea unui grafic al dependențelor reciproce ale produselor software și bibliotecilor , ceea ce duce la dificultatea instalării noi și a eliminării produselor vechi. În cazuri complexe, diferite produse software instalate necesită versiuni diferite ale aceleiași biblioteci. În cele mai complexe cazuri, un produs poate necesita indirect două versiuni ale aceleiași biblioteci simultan. [1] Problemele de dependență apar cu genericepachete/biblioteci în care alte pachete au dependențe de versiuni incompatibile și diferite ale pachetelor comune. Dacă este instalată o versiune a unui pachet / bibliotecă partajată, automatul / programatorul / administratorul de testare va trebui să obțină versiuni noi sau vechi ale pachetelor dependente pentru a rezolva această problemă . Acest lucru, la rândul său, poate sparge alte pachete dependente și poate adăuga probleme unui alt set de pachete, creând astfel un adevărat iad.
De obicei, în loc să „reinventeze roata”, software-ul este conceput pentru a obține funcționalitatea necesară de la alte componente software care sunt disponibile dezvoltatorului sau care au fost dezvoltate în altă parte. Acest lucru poate fi comparat cu modul în care oamenii care construiesc o casă pot cumpăra materiale gata făcute, cum ar fi cărămizi, ferestre și uși, în loc să le creeze ei înșiși.
Chiar și pentru constructor, poate fi o problemă dacă clădirea este făcută pentru un anumit tip de ușă și sunt disponibile doar uși cu specificații diferite. Cu toate acestea, în lumea software-ului, unde componentele evoluează foarte repede și sunt foarte dependente unele de altele, această problemă devine mult mai relevantă.
Problema „iadului dependenței” poate fi privită ca un anti- model , în care vina este nu atât a vânzătorilor de produse , cât a cadrului în care ar trebui să fie incluși.
„Iadul dependenței” ia mai multe forme [2] :
Aplicația depinde de un număr mare de biblioteci mari care necesită descărcări lungi și ocupă mult spațiu pe disc . Este posibil ca o aplicație să fie construită pe o anumită platformă (de exemplu , Java ) și să necesite instalarea acelei platforme, în timp ce 99% dintre celelalte aplicații ale dvs. nu necesită suport pentru această platformă. Acesta este un caz particular al problemei atunci când fie o aplicație utilizează o mică parte dintr-o platformă mare și în cele din urmă necesită instalarea întregii platforme (care poate fi rezolvată doar prin refactorizarea aplicației), fie o aplicație mică se bazează pe un număr mare. a diferitelor biblioteci în același timp.
Aplicația depinde de biblioteca „A” care depinde de biblioteca „B”, ... care la rândul ei depinde de biblioteca „Z”. Acesta este un caz special al problemei multor dependențe , cu diferența că un număr mare de dependențe sunt complicate de relația lor complicată și lungă, care trebuie rezolvată manual. (Utilizatorul instalează aplicația, dar i se cere să instaleze biblioteca „A”, instalează biblioteca „A”, dar când încearcă să facă acest lucru, biblioteca „A” solicită instalarea bibliotecii „B”, etc.
Uneori, un lanț de dependență atât de lung poate duce la conflicte în care diferite componente ale lanțului necesită versiuni diferite ale aceluiași pachet sau bibliotecă. (vezi dependențe conflictuale ) Astfel de lanțuri lungi de dependențe ar trebui să fie tratate de managerii de pachete , care fac acest lucru automat, în loc să forțeze utilizatorul să le rezolve manual, ceea ce poate lăsa dependențele parțial nesatisfăcute (nu toți instalatorii de biblioteci vă reamintesc în mod constant de toate utilizator de dependențe).
Dacă „Aplicația 1” depinde de biblioteca „A” versiunea 1.2 , iar „Aplicația 2” depinde de aceeași bibliotecă „A”, dar deja versiunea 1.3 și versiuni diferite ale bibliotecii „A” nu pot fi instalate în același timp, atunci „Aplicația 1” și „Aplicația 2” nu pot fi utilizate în același timp (sau chiar instalate dacă instalatorii verifică dependențe).
Atunci când este posibil să utilizați diferite versiuni ale bibliotecii în același timp, acest lucru este rezolvat prin instalări paralele ale diferitelor versiuni ale bibliotecii. În caz contrar, instalarea folosind noua versiune a bibliotecii trebuie să fie însoțită de eliminarea versiunii vechi a bibliotecii și, în consecință, a tuturor programelor care depind de aceasta. vor fi inoperabili.
Pe sistemele Linux , această problemă apare adesea când se încearcă instalarea pachetelor de la diferiți dezvoltatori în sistem care nu sunt destinate acestei versiuni a sistemului. Într-un astfel de caz, satisfacerea unui lanț lung de dependențe de pachete poate duce chiar la, de exemplu, solicitarea unei versiuni diferite a bibliotecii glibc , una dintre cele mai importante biblioteci de sistem fundamentale . Dacă se întâmplă acest lucru, utilizatorului i se va solicita să elimine mii de pachete, ceea ce este în esență același cu eliminarea, de exemplu, a 80% din sistem, inclusiv shell-uri grafice și sute de programe diferite.
O situație în care aplicația „A” versiunea 2 depinde de aplicația „B”, care depinde de aplicația „C”, care, la rândul ei, depinde de aplicația „A”, dar versiunea 1. Acest lucru duce la faptul că în sisteme batch precum RPM sau DPKG , utilizatorul trebuie să instaleze două versiuni ale aceleiași aplicații sursă „A”, care ar putea să nu fie permise sau permise de managerul de pachete. Cu toate acestea, pe sistemele Linux , prezența unei dependențe circulare este cel mai adesea rezultatul unei înțelegeri greșite de către utilizator cu privire la modul de utilizare a sistemului de operare și a managerului său de pachete.
Cea mai evidentă (și folosită în mod obișnuit) soluție la problemă este numerotarea standardizată a versiunilor, în care software-ul folosește un număr specific pentru fiecare versiune (aka major version ) și un număr suplimentar pentru versiunea minoră (aka minor version ), cum ar fi: 10.1 , sau 5.7 . O versiune majoră se modifică doar atunci când programul care are acea versiune nu mai este compatibil cu programul actualizat, ținând cont de modificările aduse acestuia. O versiune minoră se poate modifica chiar și cu mici modificări ale codului care nu împiedică software-ul terță parte să lucreze cu programul dezvoltat. În astfel de cazuri, programele terțe pot solicita pur și simplu o componentă care are o anumită versiune majoră și o versiune minoră arbitrară , minoră (mai mare sau egală cu versiunea minoră specificată). Totul va continua să funcționeze și dependențele vor fi rezolvate cu succes chiar dacă versiunea minoră s-a schimbat.
Soluția de numerotare a versiunilor poate fi îmbunătățită făcând ca numerotarea versiunilor să fie acceptată la nivel de sistem de operare . Acest lucru va permite aplicației să interogheze modulul/biblioteca după numele său unic și să stabilească restricții asupra numerelor de versiune, utilizând eficient sistemul de operare. Un modul partajat poate fi plasat într-un magazin central fără riscul eșecului aplicațiilor care depind de versiunile anterioare sau ulterioare ale acelui modul. Fiecare versiune primește propria sa intrare în depozit, fiind alături de alte versiuni ale aceluiași modul. O astfel de soluție a fost folosită în sistemul de operare Windows încă din Windows Vista , unde Global Assembly Cache este o implementare a unui astfel de depozit central cu servicii asociate și un manager de pachete integrat.
Managerii de pachete gestionați prin program pot actualiza componente software independente, rezolvând în același timp incompatibilitățile majore ale versiunilor.
Multe distribuții Linux moderne au manageri de pachete bazați pe depozite pentru a face față problemei dependențelor. Aceste sisteme sunt un strat peste RPM , dpkg sau alte sisteme de pachete și sunt concepute pentru a rezolva automat dependențele prin căutarea într-un depozit de software predefinit . De obicei, aceste depozite de software sunt FTP sau site-uri web, directoare pe un computer local sau distribuite prin rețele de computere sau, mai puțin frecvent, directoare pe medii amovibile, cum ar fi CD-uri sau DVD-uri. Acest lucru elimină iadul de dependență pentru pachetele software stocate în depozite care sunt de obicei întreținute de furnizorii de distribuție Linux și oglinzile din întreaga lume. De asemenea, aceste depozite sunt adesea mari, este imposibil să aveți toate piesele de software în ele simultan, așa că iadul de dependență se poate instala în continuare. În orice caz, întreținerii depozitelor se confruntă într-un fel sau altul într-un fel sau altul. [3] Exemple de astfel de sisteme sunt APT , YUM , urpmi , Zypper , Portage , Pacman și altele.
PC-BSD ( sistem de operare bazat pe FreeBSD ) până la versiunea 8.2 se ocupă de iadul dependențelor plasând pachete și dependențe în directoare containere autonome, evitând astfel deteriorarea bibliotecilor de sistem în timpul actualizărilor sau altor modificări ale acestora. Sistemul PC-BSD folosește „PBI” (Push Button Installer) ca principal manager de pachete. [patru]
Deoarece diferite componente de software au dependențe diferite, este posibil să intrați într-un cerc vicios al cerințelor de dependență sau (mai rău poate) într-un arbore de cerințe în continuă expansiune , deoarece fiecare pachet nou necesită încă câteva instalații. Sisteme precum APT pot permite acest lucru oferind utilizatorului o gamă de opțiuni din care să aleagă și permițându-i să le accepte sau să le respingă după cum dorește.
Dacă aplicația software este proiectată în așa fel încât dezvoltatorii săi să poată adapta cu ușurință interfața care se ocupă cu sistemul de operare , managerul de ferestre sau mediul desktop la standarde noi sau în schimbare, atunci programatorii ar trebui să controleze doar notificările de la creatorii de mediu sau componente și adaptează rapid actualizările software la actualizările utilizatorilor, costurile ar fi minime și consumatoare de timp, upgrade-uri costisitoare nu ar fi necesare. Această metodă ar încuraja programatorii să se angajeze activ cu cei de care depind pentru a menține un proces rezonabil de notificare care să nu împovăreze pe nimeni implicat.
O altă abordare pentru prevenirea problemelor de dependență este de a implementa software prin intermediul dispozitivului . Dependențe sunt încapsulate într-un modul, permițând utilizatorilor să nu-și facă griji cu privire la dependențele din software. Aceasta este preocuparea dezvoltatorilor de software.
În acest caz, ne referim la aplicații (sau versiuni ale aplicațiilor standard) care funcționează în mediul lor propriu, închis și autosuficient și au dependențe minime de bibliotecile de sistem. Toate componentele necesare pentru funcționarea programului sunt adăugate în etapa de dezvoltare internă, codare și ambalare, în timp ce fișierele și componentele importante pentru funcționarea programului sunt încapsulate cât mai mult posibil într-un mediu independent de restul sistemul, ca urmare, printr-un impact minim cu restul sistemului, este posibil să se evite majoritatea problemelor cu dependențele nerezolvate. Poate funcționa adesea indiferent de sistemul pe care rulează aplicația. Aplicațiile din RISC OS și ROX Desktop într-un mediu Linux folosesc directoare de aplicații , lucrând astfel pe un principiu similar: un program cu toate dependențele sale este conținut în propriul director (folder) autonom. [5]
Pe anumite platforme software, conceptul de „iad de dependență” capătă propriul nume, în funcție de numele componentelor aflate în conflict.