A függőségi pokol egy konfigurációkezelési anti -minta, a szoftvertermékek és -könyvtárak kölcsönös függőségei grafikonjának növekedése , ami az új termékek telepítésének és a régi termékek eltávolításának nehézségéhez vezet . Bonyolult esetekben a különböző telepített szoftvertermékekhez ugyanazon könyvtár különböző verzióira van szükség. A legbonyolultabb esetekben egy termék közvetetten megkövetelheti ugyanannak a könyvtárnak két verzióját egyszerre. [1] Függőségi problémák fordulnak elő megosztott csomagokkal/könyvtárakkal, ahol néhány más csomag a megosztott csomagok nem kompatibilis és eltérő verzióitól függ. Ha egy megosztott csomag / könyvtár egy verziója van telepítve, a tesztautomatikusnak / programozónak / adminisztrátornak be kell szereznie a függő csomagok új vagy régi verzióit a probléma megoldásához . Ez viszont feltörhet más függő csomagokat, és problémákat adhat egy másik csomagkészlethez, így valódi poklot teremthet.
Általában a „kerék újrafeltalálása” helyett a szoftvert úgy alakítják ki, hogy a szükséges funkcionalitást a fejlesztő rendelkezésére álló vagy máshol kifejlesztett szoftverösszetevőkből szerezze be. Ez összehasonlítható azzal, ahogyan a házat építő emberek vásárolhatnak kész anyagokat, például téglákat, ablakokat és ajtókat, ahelyett, hogy maguk készítenék azokat.
Még az építtető számára is gondot okozhat, ha az épület egy bizonyos típusú ajtóra készül, és csak eltérő specifikációjú ajtók állnak rendelkezésre. A szoftverek világában azonban, ahol az összetevők nagyon gyorsan fejlődnek, és nagymértékben függnek egymástól, ez a probléma sokkal aktuálisabbá válik.
A „függőségi pokol” problémája egy anti -mintaként fogható fel, ahol a hiba nem annyira a termékszállítókban van, mint inkább abban, hogy milyen keretbe kell őket bevonni.
A „függőségi pokol” többféle formát ölt [2] :
Az alkalmazás nagyszámú nagy könyvtártól függ, amelyek hosszú letöltést igényelnek, és sok lemezterületet foglalnak el . Lehetséges, hogy egy alkalmazás egy adott platformra épül (például Java ), és ezt a platformot telepíteni kell, míg a többi alkalmazás 99%-a nem igényel támogatást ehhez a platformhoz. Ez egy speciális esete annak a problémának, amikor egy alkalmazás egy nagy platform kis részét használja, és végül a teljes platform telepítését igényli (amit csak az alkalmazás újrafaktorálásával lehet megoldani ), vagy egy kis alkalmazás nagy számra támaszkodik. különböző könyvtárak egyidejűleg.
Az alkalmazás az "A" könyvtártól függ, amely a "B" könyvtártól függ, ... amely viszont a "Z" könyvtártól függ. Ez a sok függőség problémájának speciális esete , azzal a különbséggel, hogy sok függőséget bonyolít bonyolult és hosszadalmas kapcsolatuk, amelyet manuálisan kell megoldani. (A felhasználó telepíti az alkalmazást, de megkérik, hogy telepítse az "A" könyvtárat, telepíti az "A" könyvtárat, de amikor ezt megpróbálja, az "A" könyvtár a "B" könyvtár telepítését kéri stb.
Néha egy ilyen hosszú függőségi lánc konfliktusokhoz vezethet, ahol a lánc különböző összetevői ugyanannak a csomagnak vagy könyvtárnak különböző verzióit igénylik. ( lásd az ütköző függőségek _ _ függőségek felhasználója).
Ha az „1. alkalmazás” az „A” könyvtár 1.2 -es verziójától függ, a „2. alkalmazás” pedig ugyanattól az „A” könyvtártól, de már az 1.3 -as verziótól függ , és az „A” könyvtár különböző verziói nem telepíthetők egyszerre, akkor Az „Application 1” és az „App2” nem használható egyszerre (sőt nem is telepíthető, ha a telepítők ellenőrzik a függőségeket).
Ha lehetőség van a könyvtár különböző verzióinak egyidejű használatára, ezt a könyvtár különböző verzióinak párhuzamos telepítésével oldják meg. Ellenkező esetben a könyvtár új verziójával történő telepítést a könyvtár régi verziójának, és ennek megfelelően az összes attól függő program eltávolításának kell kísérnie. működésképtelenné válnak.
Linux rendszereken ez a probléma gyakran akkor jelentkezik, amikor különböző fejlesztőktől származó olyan csomagokat próbálnak telepíteni a rendszerbe, amelyek nem a rendszer ezen verziójához készültek. Ilyen esetben a csomagfüggőségek hosszú láncolatának kielégítése akár ahhoz is vezethet, hogy például egy másik verziót kérünk a glibc könyvtárból , amely az egyik legfontosabb, alapvető rendszerkönyvtár . Ha ez megtörténik, a felhasználó több ezer csomag eltávolítását kéri, ami lényegében ugyanaz, mint például a rendszer 80%-ának eltávolítása , beleértve a grafikus héjakat és több száz különböző programot.
Olyan helyzet, amikor az "A" alkalmazás 2-es verziója a "B" alkalmazástól függ, amely a "C" alkalmazástól függ, amely viszont az "A" alkalmazástól függ, de az 1. verzió. Ez oda vezet, hogy az olyan kötegelt rendszerekben, mint az RPM ill . DPKG , a felhasználónak telepítenie kell ugyanannak az "A" forrásalkalmazásnak két verzióját, amelyet a csomagkezelő nem engedélyez vagy engedélyez. Linux rendszereken azonban a körkörös függőség jelenléte leggyakrabban annak az eredménye, hogy a felhasználó félreérti az operációs rendszer és annak csomagkezelőjének használatát.
A probléma legkézenfekvőbb (és leggyakrabban használt) megoldása a szabványos verziószámozás, amelyben a szoftver egy adott számot használ minden verzióhoz (más néven főverzió ), és egy további számot a mellékverzióhoz (más néven minor verzió ), például: 10.1 , vagy 5.7 . Egy nagyobb verzió csak akkor változik, ha az adott verziót tartalmazó program már nem kompatibilis a frissített programmal, figyelembe véve a rajta végrehajtott változtatásokat. Egy kisebb verzió még a kód olyan kis változtatásaival is megváltozhat, amelyek nem akadályozzák meg a harmadik féltől származó szoftverek együttműködését a kifejlesztett programmal. Ilyen esetekben a harmadik féltől származó programok egyszerűen kérhetnek egy olyan összetevőt, amelynek van egy adott főverziója, és egy tetszőleges mellékváltozatot (a megadott mellékverziónál nagyobb vagy azzal egyenlő). Minden tovább fog működni, és a függőségek sikeresen feloldódnak még akkor is, ha a kisebb verzió megváltozott.
A verziószámozási megoldás javítható a verziószámozás támogatásával az operációs rendszer szintjén . Ez lehetővé teszi az alkalmazás számára, hogy lekérdezze a modult/könyvtárat annak egyedi neve alapján, és korlátozza a verziószámokat, hatékonyan használva az operációs rendszert. Egy megosztott modul elhelyezhető egy központi tárolóban anélkül, hogy fennállna a modul korábbi vagy későbbi verzióitól függő alkalmazások meghibásodásának kockázata. Mindegyik verzió saját bejegyzést kap a tárolóban, amely ugyanazon modul más verziói mellett található. Ilyen megoldást használnak a Windows operációs rendszerben a Windows Vista óta , ahol a Global Assembly Cache egy ilyen központi tár megvalósítása a kapcsolódó szolgáltatásokkal és egy integrált csomagkezelővel.
A programozottan felügyelt csomagkezelők frissíthetik a független szoftverösszetevőket, miközben feloldják a főbb verzió-összeférhetetlenségeket.
Sok modern Linux disztribúció rendelkezik lerakatokon alapuló csomagkezelőkkel , amelyek kezelik a függőségek problémáját. Ezek a rendszerek egy réteg az RPM , dpkg vagy más csomagrendszerek tetején, és úgy vannak kialakítva, hogy automatikusan feloldják a függőségeket egy előre meghatározott szoftvertárban való kereséssel . Ezek a szoftvertárak jellemzően FTP -k vagy webhelyek, helyi számítógépen lévő vagy számítógépes hálózatokon elosztott könyvtárak , vagy ritkábban cserélhető adathordozókon, például CD-n vagy DVD-n lévő könyvtárak. Ez kiküszöböli a függőségi poklot az olyan lerakatokban tárolt szoftvercsomagoknál, amelyeket általában Linux-terjesztési szolgáltatók és tükrök tartanak fenn világszerte. Ezenkívül ezek a tárolók gyakran nagyok, lehetetlen, hogy az összes szoftver egyszerre legyen bennük, így a függőségi pokol még mindig beállhat. Mindenesetre az adattár-karbantartók ilyen vagy olyan módon szembesülnek a függőségi pokollal. [3] Ilyen rendszerek például az APT , YUM , urpmi , Zypper , Portage , Pacman és mások.
A PC-BSD ( FreeBSD - alapú operációs rendszer ) a 8.2-es verzióig úgy kezeli a függőségi poklot, hogy a csomagokat és a függőségeket önálló konténerkönyvtárakba helyezi, így elkerülhető a rendszerkönyvtárak károsodása a frissítések vagy egyéb változtatások során. A PC-BSD rendszer a "PBI"-t (Push Button Installer) használja fő csomagkezelőként. [négy]
Mivel a különböző szoftverek eltérő függőséggel rendelkeznek, előfordulhat, hogy a függőségi követelmények ördögi körébe kerülhetünk , vagy (talán még rosszabb) a követelmények folyamatosan bővülő fájába , mivel minden új csomaghoz néhány további telepítésre van szükség. Az olyan rendszerek, mint például az APT , ezt úgy tehetik lehetővé, hogy a felhasználónak számos választási lehetőséget biztosítanak, és lehetővé teszik számukra, hogy tetszés szerint elfogadják vagy elutasítsák azokat.
Ha az alkalmazásszoftver úgy van megtervezve, hogy fejlesztői könnyen hozzá tudják igazítani az operációs rendszerrel , ablakkezelővel vagy asztali környezettel foglalkozó felületet az új vagy változó szabványokhoz, akkor a programozóknak csak a környezet létrehozóitól, ill. könyvtári tervezők. komponenseket és szoftverfrissítéseiket gyorsan hozzáigazítják a felhasználói frissítésekhez, a költségek minimálisak és időigényesek lennének, nem lenne szükség költséges frissítésekre. Ez a módszer arra ösztönözné a programozókat, hogy aktívan vegyenek részt azokkal, akiktől függenek, ésszerű értesítési folyamat fenntartása érdekében, amely nem terhel senkit.
A függőségi problémák megelőzésének másik módja a szoftver telepítése a készüléken keresztül . A függőségek egy modulba vannak beépítve, így a felhasználók ne aggódjanak a szoftverben lévő függőségek miatt. Ez a szoftverfejlesztők gondja.
Ebben az esetben olyan alkalmazásokat (vagy szabványos alkalmazások változatait) értjük, amelyek saját, zárt és önellátó környezetben működnek, és minimális függőséggel rendelkeznek a rendszerkönyvtáraktól. A program működéséhez szükséges összes komponens hozzáadásra kerül a házon belüli fejlesztés, kódolás és csomagolás szakaszában, míg a program működéséhez fontos fájlok és komponensek a lehető legnagyobb mértékben a többitől független környezetben kerülnek beágyazásra . a rendszer, ennek eredményeként a rendszer többi részével való minimális hatás révén elkerülhető a legtöbb probléma a megoldatlan függőségekkel. Gyakran működhet függetlenül attól, hogy melyik rendszeren fut az alkalmazás. A RISC OS és a ROX Desktop alkalmazásai Linux környezetben alkalmazáskönyvtárakat használnak , így hasonló elven működnek: a program minden függőségével a saját önálló könyvtárában (mappájában) található. [5]
Egyes szoftverplatformokon a „függőségi pokol” fogalma saját nevet kap, az ütköző összetevők nevétől függően.