Závislostní peklo je anti-vzorec pro správu konfigurace , růst grafu vzájemných závislostí softwarových produktů a knihoven , což vede k potížím při instalaci nových a odstraňování starých produktů. Ve složitých případech vyžadují různé nainstalované softwarové produkty různé verze stejné knihovny. V nejsložitějších případech může jeden produkt nepřímo vyžadovat dvě verze stejné knihovny najednou. [1] Problémy se závislostmi se vyskytují u sdílených balíčků/knihoven, kde některé jiné balíčky mají závislosti na nekompatibilních a různých verzích sdílených balíčků. Pokud je nainstalována jedna verze sdíleného balíčku / knihovny , bude muset testovací automat / programátor / administrátor získat nové nebo staré verze závislých balíčků , aby tento problém vyřešil . To zase může rozbít další závislé balíčky a přidat problémy do jiné sady balíčků, čímž vznikne skutečné peklo.
Obvykle je software namísto „znovuobjevování kola“ navržen tak, aby získal potřebnou funkčnost z jiných softwarových komponent , které jsou vývojáři k dispozici nebo byly vyvinuty jinde. Dá se to přirovnat k tomu, jak si lidé, kteří staví dům, mohou kupovat hotové materiály, jako jsou cihly, okna a dveře, než aby je sami vytvářeli.
I pro stavebníka může být problém, pokud je stavba vyrobena pro určitý typ dveří a k dispozici jsou pouze dveře s jinou specifikací. Ve světě softwaru, kde se komponenty vyvíjejí velmi rychle a jsou na sobě velmi závislé, se však tento problém stává mnohem aktuálnějším.
Problém „pekla závislosti“ lze vnímat jako anti- vzorec , kde chyba nespočívá ani tak v prodejcích produktů , jako v rámci , do kterého by měli být zahrnuti.
„Peklo závislosti“ má několik podob [2] :
Aplikace závisí na velkém počtu velkých knihoven, které vyžadují dlouhé stahování a zabírají hodně místa na disku . Je možné, že je aplikace postavena na konkrétní platformě (například Java ) a vyžaduje instalaci této platformy, zatímco 99 % vašich ostatních aplikací podporu této platformy nevyžaduje. Toto je konkrétní případ problému, kdy buď aplikace využívá malou část velké platformy a nakonec vyžaduje instalaci celé platformy (což lze vyřešit pouze refaktorizací aplikace), nebo malá aplikace spoléhá na velké množství různých knihoven současně.
Aplikace závisí na knihovně "A", která závisí na knihovně "B", ... která zase závisí na knihovně "Z". Toto je speciální případ problému mnoha závislostí s tím rozdílem, že velké množství závislostí je komplikováno jejich složitým a zdlouhavým vztahem, který je nutné řešit ručně. (Uživatel si nainstaluje aplikaci, ale je požádán o instalaci knihovny „A“, nainstaluje knihovnu „A“, ale když se o to pokusí, knihovna „A“ požádá o instalaci knihovny „B“ atd.
Někdy může takto dlouhý řetězec závislostí vést ke konfliktům, kdy různé součásti řetězce vyžadují různé verze stejného balíčku nebo knihovny. (viz konfliktní závislosti ) S tak dlouhými řetězci závislostí by se měli vypořádat správci balíčků , kteří to dělají automaticky, místo toho, aby nutili uživatele je řešit ručně, což může způsobit, že závislosti nebudou částečně spokojeny (ne všichni instalátoři knihoven vám neustále připomínají všechny své uživatel závislostí).
Pokud "Aplikace 1" závisí na knihovně "A" verze 1.2 a "Aplikace 2" závisí na stejné knihovně "A", ale již verze 1.3 a různé verze knihovny "A" nelze nainstalovat současně, pak "Aplikace 1" a "App2" nelze používat současně (ani nainstalovat, pokud instalátoři zkontrolují závislosti).
Když je možné používat různé verze knihovny současně, řeší se to paralelními instalacemi různých verzí knihovny. V opačném případě musí být instalace pomocí nové verze knihovny doprovázena odstraněním staré verze knihovny a tedy i všech programů, které jsou na ní závislé. budou nefunkční.
Na systémech Linux se tento problém často vyskytuje při pokusu o instalaci balíčků od různých vývojářů do systému, které nejsou určeny pro tuto verzi systému. V takovém případě může uspokojení dlouhého řetězce závislostí balíčků vést například k požadavku na jinou verzi knihovny glibc , jedné z nejdůležitějších základních systémových knihoven . Pokud k tomu dojde, uživatel bude vyzván k odstranění tisíců balíčků, což je v podstatě totéž, jako když odstraníte například 80 % systému včetně grafických shellů a stovek různých programů.
Situace, kdy aplikace "A" verze 2 závisí na aplikaci "B", která závisí na aplikaci "C", která zase závisí na aplikaci "A", ale verze 1. To vede k tomu, že v dávkových systémech jako RPM resp . DPKG , uživatel musí nainstalovat dvě verze stejné zdrojové aplikace "A", což nemusí být povoleno nebo povoleno správcem balíčků. V systémech Linux je však přítomnost kruhové závislosti nejčastěji výsledkem nepochopení uživatele, jak používat operační systém a jeho správce balíčků.
Nejviditelnějším (a běžně používaným) řešením problému je standardizované číslování verzí, ve kterém software používá specifické číslo pro každou verzi (aka hlavní verze ) a další číslo pro vedlejší verzi (aka vedlejší verze ), jako například: 10.1 nebo 5.7 . Hlavní verze se změní pouze v případě, že program, který má tuto verzi, již není kompatibilní s aktualizovaným programem, a to s ohledem na změny provedené v něm. Menší verze se může změnit i malými změnami v kódu, které neblokují software třetích stran v práci s vyvinutým programem. V případech, jako je tento, mohou programy třetích stran jednoduše požadovat komponentu, která má specifickou hlavní verzi a libovolnou vedlejší, vedlejší verzi (větší nebo rovnou zadané vedlejší verzi). Vše bude nadále fungovat a závislosti budou úspěšně vyřešeny, i když se změnila vedlejší verze.
Řešení číslování verzí lze vylepšit podporou číslování verzí na úrovni operačního systému . To umožní aplikaci dotazovat se na modul/knihovnu podle jejího jedinečného názvu a nastavit omezení pro čísla verzí efektivně pomocí operačního systému. Sdílený modul lze umístit do centrálního úložiště bez rizika selhání aplikací, které jsou závislé na předchozích nebo následujících verzích daného modulu. Každá verze má svůj vlastní záznam v úložišti a je vedle jiných verzí stejného modulu. Takové řešení se používá v operačním systému Windows od Windows Vista , kde je Global Assembly Cache implementací takového centrálního úložiště s přidruženými službami a integrovaným správcem balíčků.
Programově spravovaní správci balíčků mohou aktualizovat nezávislé softwarové komponenty a zároveň řešit hlavní nekompatibility verzí.
Mnoho moderních linuxových distribucí má správce balíčků založené na repozitářích , aby se vypořádali s problémem závislostí. Tyto systémy jsou vrstvou nad RPM , dpkg nebo jinými systémy balíčků a jsou navrženy tak, aby automaticky řešily závislosti prohledáváním předdefinovaného softwarového úložiště . Obvykle jsou tato softwarová úložiště FTP nebo webové stránky, adresáře na místním počítači nebo distribuované přes počítačové sítě , nebo méně často adresáře na vyměnitelných médiích, jako jsou CD nebo DVD. To eliminuje peklo závislostí na softwarových balíčcích uložených v úložištích, která jsou obvykle udržována poskytovateli distribuce Linuxu a zrcadly po celém světě. Tyto repozitáře jsou také často velké, není možné v nich mít všechny kusy softwaru najednou, takže závislost může stále nastat. V každém případě správci repozitářů čelí peklu závislosti tak či onak. [3] Příklady takových systémů jsou APT , YUM , urpmi , Zypper , Portage , Pacman a další.
PC-BSD ( operační systém založený na FreeBSD ) až do verze 8.2 řeší peklo závislostí umístěním balíčků a závislostí do samostatných adresářů kontejnerů, čímž se zabrání poškození systémových knihoven během aktualizací nebo jiných změn v nich. Systém PC-BSD používá jako hlavního správce balíčků "PBI" (Push Button Installer). [čtyři]
Protože různé části softwaru mají různé závislosti, je možné se dostat do začarovaného kruhu požadavků na závislosti nebo (možná ještě horšího) do stále se rozšiřujícího stromu požadavků , protože každý nový balíček vyžaduje instalaci několika dalších. Systémy jako APT to mohou umožnit tím, že uživateli poskytnou řadu možností na výběr a umožní mu je přijmout nebo odmítnout, jak si přeje.
Pokud je aplikační software navržen tak, aby jeho vývojáři byli schopni snadno přizpůsobit rozhraní , které se zabývá operačním systémem , správcem oken nebo desktopovým prostředím novým nebo měnícím se standardům, pak by programátoři museli ovládat pouze upozornění od tvůrců prostředí resp. Návrháři knihoven, komponenty a rychle přizpůsobí své aktualizace softwaru aktualizacím uživatelů, náklady by byly minimální a časově náročné, nákladné upgrady by nebyly nutné. Tato metoda by povzbudila programátory, aby aktivně spolupracovali s těmi, na kterých jsou závislí, aby zachovali přiměřený proces oznamování, který nikoho nezatěžuje.
Dalším způsobem, jak předejít problémům se závislostí, je nasazení softwaru prostřednictvím zařízení . Závislosti jsou zapouzdřeny v modulu, což uživatelům umožňuje nestarat se o závislosti v softwaru. To je starostí softwarových vývojářů.
V tomto případě máme na mysli aplikace (nebo verze standardních aplikací), které pracují ve vlastním, uzavřeném a soběstačném prostředí a mají minimální závislosti na systémových knihovnách. Všechny komponenty potřebné pro provoz programu jsou přidávány ve fázi vlastního vývoje, kódování a balení, zatímco soubory a komponenty důležité pro provoz programu jsou co nejvíce zapouzdřeny v prostředí nezávislém na zbytku systému je tak minimálním dopadem na zbytek systému možné předejít většině problémů s nevyřešenými závislostmi. Často může fungovat bez ohledu na systém, na kterém aplikace běží. Aplikace v RISC OS a ROX Desktop v prostředí Linuxu používají adresáře aplikací , fungují tedy na podobném principu: program se všemi svými závislostmi je obsažen ve svém vlastním samostatném adresáři (složce). [5]
Na určitých softwarových platformách má pojem „peklo závislosti“ své vlastní jméno v závislosti na názvu konfliktních komponent.