Verziópokol
A verziópokol egy köznyelvi megnevezés arra, hogy a felhasználó azért nem tud telepíteni egy programot, mivel annak egy másik programnak arra a verziójára van szüksége, amit nem telepíthet, mivel más programok ugyanennek a függőségnek egy másik verzióját használják.[1]
Másként kifejezve, a problémát egy olyan megosztott könyvtár okozza, amit több más program is használ. Ha a felhasználó mégis telepíteni vagy használni akarja az új programot, akkor le kell mondania más, már telepített programokról, amivel a rendszer akár használhatatlanná válhat.
Ideális esetben az újabb programverzió a régi verzióval teljes mértékben visszafelé kompatibilis, így elegendő lenne csak az új verziót használni. De különböző okokból - általában a fejlesztési költségek jelentős növekedése miatt - a szállítók gyakran úgy döntenek, hogy az új verzió kiadásakor már szakítanak a kompatibilitással. Ilyenkor is megoldás lehetne még az, hogy egy programcsomagnak több különböző verziója is telepíthető lenne, ám ez legtöbbször nem lehetséges.
Típusai szerkesztés
A verziópokol többféle formában is megjelenhet.
Sok függőség szerkesztés
A telepítendő programnak sok könyvtárra van szüksége, emiatt a telepítéshez hosszas letöltésre és nagy tárhelyre van szükség. Ez rontja a portolhatóságot, mivel minden függőséget is portolni kell. Nehéz megtalálni az összes függőséget, amin segíthet, ha össze vannak gyűjtve egy tárolóba.
A függőségek használata többnyire elkerülhetetlen, mivel azok olyan szolgáltatásokat nyújtanak, amiket a program szerzői nem tudnának megvalósítani. Például egy Java programnak Java virtuális gép kell, hogy futtatni lehessen. Néha a függőségek száma csökkenthető például refaktorálással, ha a könyvtárnak csak egy kisebb részét használják. A probléma kisebb a kisebb, egyszerűbb alkalmazásoknál.[2]
Hosszú függőségi lánc szerkesztés
Néha a függőségi láncok hosszúvá válnak, azaz nemcsak hogy sok a csomag, de sokáig kell visszamenni a láncban a telepítéshez. Például egy app függ a liba könyvtártól, ami a libb-től, és így tovább, egészen a libz-ig. Ez annyiban különbözik a fenti esettől, hogy ha a függőségi fa alacsony, akkor a felhasználó előbb ismeri meg az összes telepítendő csomagot. Ha viszont nagyon sok szint van, akkor sokáig kell keresgélni, mire minden megvan. Mindkét esetben előfordulhat, hogy az alkalmazás nem telepíthető, mivel a szükséges csomagok függőségei ütköznek, egy csomagnak több verziójára lenne szükség.[3] Ennek kiderítésére egy automatikus csomagkezelő a legjobb, ami nemcsak egyszerre mutatja és telepíti, ha lehet, az összes csomagot, de észreveszi a körkörös függőségeket is, melyek egyébként észrevétlenek maradnának.
Függőségi konfliktusok szerkesztés
A függőségi konfliktusra példa, hogy ha app1 függ a libfoo 1.2 csomagtól, és az app2 függ a libfoo 1.3 csomagtól, és nem telepíthetők a libfoo különböző verziói, akkor app1 és app2 nem használható, vagy akár nem is telepíthető együtt. Linux rendszereken jellemző, hogy különböző terjesztők csomagjai egy hosszú függőségi sor mélyén a C standard könyvtár különböző verziói ütköznek, amin több ezernyi könyvtár és program alapul.
Egy másik fajtája ennek a káró függőség. Ekkor az A programnak szüksége van a B és a C csomagokra, de azok egy D csomag különböző verzióit igénylik. Mivel egy programban egy könyvtárnak csak egy verziója szerepelhet, azért az A program nem fordul. Jól karban tartott tárolók (Debian és származékai) esetén a probléma többnyire csak külső forrásból származó csomagokkal fordulhat elő;[4] míg más tárolók, például a yum csomagtelepítős Linuxok esetén ez a probléma gyakori. Ezt használja például a CentOS és a Red Hat Enterprise Linux[5]
A megoldás az lenne, ha egy programnak vagy könyvtárnak több verziója is használható lenne egymással párhuzamosan.
Körkörös függőségek szerkesztés
Körkörös függőségek esetén egy A program működésére szükség van a B program egy adott verziójára, és megfordítva, akár indirekt is, a B programnak is szüksége van az A csomag egy adott verziójára. A kör akármilyen hosszú lehet, így a kapcsolat nem mindig nyilvánvaló. Bármelyik frissítése eltöri, azaz működésképtelenné teszi a körkörös függőség összes többi elemét is, így a függőség tagjai nem frissíthetők. Különösen súlyos a helyzet, ha csomagkezelőkről van szó. Az A program akár automatikus frissítése eltöri a B csomagkezelőjét is, így az nem használható a korrekt verzió visszaállítására. A megoldás letölteni és telepíteni a megfelelő verziókat, akár ideiglenes környezetben is.
Megoldások szerkesztés
Verziószámozás szerkesztés
A probléma kezelésének megkönnyítésére meg szokták különböztetni a kisebb és a nagyobb módosításokat tartalmazó verziókat egymástól. A verziószámot ponttal elhatárolt alakban szokták megadni, habár ez nem tizedestört, mivel például az 5.14 újabb, mint az 5.2, illetve ez több szintű is lehet pl. 5.14.3.1. Jelentése, hogy a hátrébb álló verziószám növelése kisebb módosításokat tartalmaz, az előrébb álló főbb verzióhoz képest, amivel a korábbi kliensek továbbra is tudnak működni; míg a nagyobb verziók sokkal szabadabban eltérnek ettől, és a klienseknek alkalmazkodniuk kell az itt bevezetett módosításokhoz. Ezzel a konvencióval a klienseknek csak a fő verziószámra kell figyelniük, a kisebb verziókra nem. Néha három vagy négy verziószám is van helyi konvencióval lekötött értelmezéssel, például az utolsó csak kisebb hibajavításokkal nőhet, új funkciót nem vihet be. (Pl. az 5.14.3.1 az az 5.14.3 verzió első hibajavító verziója.) A Semantic Versioning, rövidítve "SemVer"[6] egy példa arra, hogy alkossanak olyan technikai specifikációt, ami speciális formájú számokat használ a verziószámozás megalkotására.
A konvenció felrúgása esetén a probléma kiújul. Az adott terméket fejlesztő csapat vagy cég célja ekkor, hogy a verziószám minél nagyobb verziót mutasson, és túllépje a versenytárs verziószámát, amivel olyan nagyobb változásokat sejtetnek, amiket nem tettek meg. Ekkor a korábban megszokott szisztéma használhatatlanná válik, a kliensek sosem tudhatják, hogy például a 10.0 valóban használhatatlan-e a programjuk számára, ha korábban a 4.6-os verzióhoz alkalmazkodtak.
Több verzió együtt szerkesztés
A különböző verziókat kezelheti az operációs rendszer is. Ahelyett, hogy a csomagokat csak névvel azonosítaná, ezután névvel és verzióval azonosítja őket. A tárolóban a különböző verziók anélkül helyezhetők el, hogy eltörnék, működésképtelenné tennék azokat az alkalmazásokat, melyeknek egy másik verzió kell.
Windows szerkesztés
A Microsoft Windows a Windows Vista óta használja ezt a megoldást. Itt a Global Assembly Cache valósítja meg ezt a központi kezelőt, ami számon tartja a kapcsolódó szolgáltatásokat, és integrálva van a csomagkezelőbe.
A több verzió együtt létezésének egy speciális változata megengedi az alkalmazásoknak, hogy saját DLL-eket használjanak. A Windows File Protection a Windows 2000 óta védi a rendszer DLL-eket attól, hogy az alkalmazások felülírják őket, és a saját DLL-ek használatát helyezi előtérbe. Ez kihasználja azt a lehetőséget, hogy a helyi elérési útnak elsőbbsége van a globálissal szemben, így az alkalmazás könyvtárába telepített DLL kitakarja a rendszer DLL-eket, az alkalmazás csak ezt látja, és használja.[7]
PC-BSD szerkesztés
A PC-BSD 8.2 módszere az, hogy a felhasználói programok külön könyvtárt kapnak a /Programs alatt. A függőségeiket is a saját könyvtárukba telepítik. Így a rendszerkönyvtárak változatlanok maradnak. Ezt a saját "PBI" (Push Button Installer) intézi.[8]
Gentoo szerkesztés
A Gentoo Linux egy másik módszert használ, amivel szintén telepíthetők ugyanannak a programnak a különböző verziói.[9]
Okos csomagkezelés szerkesztés
Az okos csomagkezelők szinkronban frissítik az összetartozó verziókat, így mindig a megfelelő verziók lesznek telepítve.
Sok Linux disztribúció tárhely alapú csomagkezelést használ. Az alap csomagkezelők, például RPM, dpkg fölött van egy másik réteg, ami képes feloldani az összes függőséget a tárolóban levő programcsomagok között. Ilyenek például Apt, Yum, Urpmi, ZYpp, Portage és Pacman. A tárhelyek többnyire interneten érhetők el, weboldalakon, számítógépekre letöltött csomagokban illetve ritkábban CD és DVD lemezeken. Az elérhetőség érdekében több internetes címen is megtalálható ugyanaz a készlet. A fenntartók átvállalják a felhasználóktól a verziópokol megoldását.[4] Nagy méretük ellenére a felhasználó nem biztos, hogy mindent megtalál itt, amit akar, úgyhogy ez nem zárja ki teljesen a verziópokol lehetőségét.
Installer opciók szerkesztés
Mivel a különböző szoftvereknek különböző függőségeik vannak, könnyű olyan körkörös függőségbe bonyolódni, ahol a kör nem záródik megfelelően, vagy elveszni egy végeláthatatlan függőségi fában. Az olyan rendszerek, mint a Debian Advanced Packaging Tool ezt úgy oldják fel, hogy a felhasználó előzetesen visszakövetheti és kiválaszthatja a megfelelő verziókat.
Adaptálhatóság szerkesztés
Ha úgy tervezik az alkalmazói szoftvert, hogy a programozók könnyen adaptálódhatnak ahhoz az interfészéhez, ami az operációs rendszer felületével, az ablakkezelővel vagy az asztali környezettel foglalkozik; akkor a programozóknak csak azzal kell törődniük, hogy milyen újabb figyelmeztetéseket kapnak ezektől, így gyorsan át tudnak állni egy újabb verzióra. Ezzel elkerülik a költséges és hosszadalmas újratervezést. Ezzel a módszerrel fel lehet kelteni az igény aziránt, hogy ugyanilyen figyelmeztetési rendszett várjanak el a többi függőségtől.
Egységcsomag szerkesztés
Az egységcsomagok a magán függőségek módszerének egy továbbgondolása. A függőségeket az alkalmazás tartalmazza előzetesen integrált egységként, így a felhasználóknak nem kell foglalkozniuk a függőségekkel.
Az egységcsomagokkal készíthetők hordozható alkalmazások is. Az alkalmazás nem igényel semmilyen előre telepített programot. Tartalmaz minden szükséges függőséget és minden szükséges fájlt a saját könyvtárában. Nem okozhat függőségi problémát, még az is mindegy neki, hogy milyen operációs rendszeren fut, mivel a saját kis, lebutított környezetét is magával viheti. Hasonlóan működnek a RISC OS és a ROX Desktop Linuxból származó alkalmazásai: saját könyvtáruk tartalmazza az összes függőségüket.[10]
A módszer hátránya, hogy ha több program is ugyanazt az osztott könyvtárat igényelné, akkor azt többszörösen telepíti, ami felesleges lenne; de ha különböző verziókat igényelnek, akkor ezzel megszűnik a verziópokol. Példa lehet erre a gedit, a GIMP és az XChat Windowson, mindegyik a saját GTK+ keretrendszerét telepíti.
Platform-specifikus szerkesztés
Különböző platformokon különböző néven említik a hasonló problémákat, rendszerint a komponensek kiterjesztésével jelölve. Így létezik DLL pokol (Microsoft Windows), kiterjesztések konfliktusa (klasszikus Mac OS), JAR pokol (Java), RPM pokol (RPM-es Linux disztribúciók, például RedHat).
Jegyzetek szerkesztés
- ↑ Michael Jang. Linux annoyances for geeks. O'Reilly Media (2006). Hozzáférés ideje: 2012. február 16.
- ↑ Donald, James (2003. január 25.). „Improved Portability of Shared Libraries”, Kiadó: Princeton University. [2007. szeptember 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. április 9.)
- ↑ Stevens, Al (2001. május 1.). „It's Good Work When You Can Find It; The Dependency Carousel”. J-DDJ 26 (5), 121–124. o, Kiadó: www.drdobbs.com/blog. [2011. augusztus 11-i dátummal az eredetiből archiválva]. ISSN 1044-789X. (Hozzáférés: 2010. április 10.)
- ↑ a b Pjotr Prins: Nix fixes dependency hell on all Linux distributions. linux.com, 2008. december 22. [2015. július 8-i dátummal az eredetiből archiválva]. (Hozzáférés: 2013. május 22.) „All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible. Suppose you upgrade Firefox, and your package manager decides that you need a newer version of GTK as well. If the new GTK is not quite backward-compatible, then other applications on your system might suddenly break. In the Windows world a similar problem is known as the DLL hell, but dependency hell is just as much a problem in the Unix world, if not a bigger one, because Unix programs tend to have many external dependencies.”
- ↑ Yum Dependency Hell. [2016. december 19-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. október 13.)
- ↑ Project website: semver.org
- ↑ Anderson, Rick: The End of DLL Hell. microsoft.com, 2000. január 11. [2001. június 5-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. július 7.)
- ↑ pbiDIR
- ↑ Slotting on gentoo.org
- ↑ Application directories. (Hozzáférés: 2013. szeptember 7.)
Fordítás szerkesztés
Ez a szócikk részben vagy egészben a Dependency hell című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.