Verziópokol

A Wikipédiából, a szabad enciklopédiából
Jump to navigation Jump to search

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. A megoldás az lenne, 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 refraktorá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 tizedespontos alakban szokták megadni, habár ez nem tizedestört, mivel például az 5.14 újabb, mint az 5.2. Jelentése, hogy a kisebb verzió kisebb módosításokat tartalmaz, 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 verziószám is van, a harmadik az csak kisebb hibajavításokkal nőhet. 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 rendszer 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.

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 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.[7]

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.[8] A PC-BSD 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.[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]

  1. Michael Jang. Linux annoyances for geeks. O'Reilly Media (2006). Hozzáférés ideje: 2012. február 16. 
  2. 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 ideje: 2010. április 9.)  
  3. ^ a b Pjotr Prins: Nix fixes dependency hell on all Linux distributions. linux.com, 2008. december 22. (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.
  4. Yum Dependency Hell
  5. Project website: semver.org
  6. Slotting on gentoo.org
  7. 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.)
  8. pbiDIR
  9. 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.