MASARYKOVA UNIVERZITA FAKULTA}w¡¢£¤¥¦§¨ INFORMATIKY !"#$%&'()+,-./012345 Metody ˇrešenízávislostí v moderních distribucích DIPLOMOVÁ PRÁCE Bc. Vladimír Beneš Brno, jaro 2010 Prohlášení Prohlašuji, že tato diplomová práce je mým p ˚uvodnímautorským dílem, které jsem vypracoval samostatnˇe.Všechny zdroje, prameny a literaturu, které jsem pˇrivypracování používal nebo z nich ˇcerpal, v práci ˇrádnˇecituji s uvedením úplného odkazu na pˇríslušnýzdroj. Vedoucí práce: RNDr. Jan Kasprzak ii Podˇekování DˇekujiJindˇrichoviNovému za postˇrehya nápady. Dˇekujivšem, kteˇrí mi pomohli radou ˇcipˇripomínkou.Dˇekujivývojáˇr˚umsvobodného a open source software za nástroje, které mi pomohly tuto práci vy- tvoˇrita v neposlední ˇradˇetéž skupinˇeMonthy Python, kterou byl inspirován jazyk, ve kterém je ˇrešeníimplementováno. iii Klíˇcováslova dependency, depsolver, solving, dependency solving, libzypp, yum, apt, zypper, car test, depsolving, ˇrešitelzávislostí iv Shrnutí Linux, ale též jiné moderní operaˇcnísystémy používají speciální apli- kace pro správu software. Mezi jednotlivými kusy software jsou ˇcasto velmi komplikované vztahy – tzv. závislosti (dependency). Provádím analýzy ˇrešitel˚utˇechtozávislostí jak z funkcionálního hlediska, tak z hlediska pamˇet’ové a ˇcasovénároˇcnosti.Na základˇe tˇechtoanalýz navrhuji vlastní ˇrešenív podobˇetransparentního API pro obecný depsolver, který by mˇelbýt použitelný v existujících ba- líˇckovacíchsystémech, pˇredevšímvšak RPM. Závˇereˇcnáˇcástje vˇeno- vána srovnání mojí implementace s využívanými ˇrešitelizávislostí. v Obsah 1 Architektura systém ˚upro správu software ...... 5 1.1 Historie software management systém ˚u ...... 6 2 Dependency solvery a problém ˇrešenízávislostí ...... 7 2.1 Typy závislostí ...... 7 2.1.1 Silné (Strong) ...... 8 2.1.2 Slabé (Weak nˇekdytéž Soft) ...... 9 3 Analýza a porovnání stávajících solver ˚u ...... 10 3.1 SUSE ...... 10 3.1.1 Definice problém splnitelnosti klauzulí . . . . . 10 3.1.2 Tvoˇrenípravidel ...... 11 3.1.3 Výhody a nevýhody libzypp ...... 11 3.2 Debian ...... 12 3.2.1 Algoritmus ...... 12 3.2.2 Výhody a nevýhody APT ...... 13 3.3 Fedora ...... 14 3.3.1 Repositáˇra jeho formát ...... 14 3.3.2 Algoritmus ...... 15 3.3.3 Výhody a nevýhody depsolveru z YUMu . . . . 16 3.4 Gentoo ...... 16 3.4.1 Algoritmus ...... 18 3.4.2 Výhody a nevýhody Portage ...... 18 4 Testy ...... 20 4.1 Car test ...... 20 4.1.1 ZYpper ...... 22 4.1.2 YUM ...... 22 4.1.3 APT ...... 24 4.1.4 Moje implementace ...... 25 4.2 Test odstranˇeníglibc ...... 25 4.2.1 ZYpper ...... 26 4.2.2 YUM ...... 27 1 4.2.3 APT ...... 28 4.2.4 Moje implementace ...... 29 4.3 Test pamˇet’ové nároˇcnosti ...... 31 5 Vlastní implementace ...... 32 5.1 Architektura ...... 32 5.2 Hlavní komponenty ...... 34 5.2.1 Fronta Q ...... 34 5.2.2 Process ...... 34 5.2.3 Qtask ...... 34 QtaskInstall ...... 34 QtaskRemove ...... 35 QtaskRequire ...... 35 QtaskConflict ...... 36 5.3 Databáze a rozhraní ...... 36 5.4 Optimalizace ...... 36 6 Závˇer ...... 38 6.1 Casovᡠnároˇcnost ...... 38 6.2 Pˇresnost ...... 39 6.3 Pamˇet’ová nároˇcnost ...... 39 6.4 Cíle ...... 40 2 Úvod Velikou výhodou dnešních operaˇcníchsystém ˚uje možnost instalo- vat velké množství softwaru po síti z veˇrejnýchúložišt’. Souˇcasné uživatelské programy se vˇetšinouskládají z nˇekolikabalík ˚u,které do sebe musí pˇresnˇezapadat. Pokud máme nainstalováno nˇekolik stovek balík ˚u,tak závislosti mezi nimi mohou být znaˇcnˇekompliko- vané a jakákoliv zmˇenam ˚užezp ˚usobitnefunkˇcnostnˇekteréhopro- gramu ˇcidokonce celého systému. Abychom udrželi systém konzistentní, potˇrebujemeprogram, který se bude o tyto závislosti starat. Tyto programy se nazývají „systémy pro správu software”. Tato aplikace se stará o instalaci, odstranˇení, ale též o aktualizace softwaru. Pˇrivšech tˇechtoúkonech musí být zachován konzistentní stav a právˇetento úkol zajišt’ují ˇrešitelé zá- vislostí alias dependency solvery (nˇekdyzkrácenˇedepsolvery). V této práci se zabývám implementacemi dependency solver ˚u z nˇekolika nejrozšíˇrenˇejšíchGNU/Linux distribucí a jejich srovná- ním. Na základˇezískaných poznatk ˚unavrhuji vlastního ˇrešitele.V první kapitole je struˇcnýpopis vzniku a architektury balíˇckovacích systém ˚u,který následuje detailnˇejšírozebrání samotné resoluce (Ka- pitola 2). V další ˇcástijsou rozebrány rezoluˇcnímetody používané jednotli- vými distribuˇcníminástroji vˇcetnˇekrátkého popisu algoritm ˚ua zhod- nocení klad ˚ua zápor ˚u. Ctvrtᡠkapitola obsahuje dva soubory test ˚u, které se vˇenujíjak kvalitˇeresoluce, tak její ˇcasovénároˇcnosti.Násle- 3 duje popis architektury a nˇekteréoptimalizaˇcnímetody, které jsem použil (kapitola 5) a závˇereˇcnépasáži jsou zachyceny dosažené vý- sledky, možná zlepšení implementace a v neposlední ˇradˇetéž bu- doucí smˇeˇrováníproblematiky ˇrešenízávislostí a metod k tomu uží- vaných. 4 Kapitola 1 Architektura systém ˚upro správu software Vˇetšinasystém ˚upro správu softwaru je složena ze 3 ˇcástí:uživatel- ské rozhraní, dependency solver a backend. Tyto ˇcástijsou uspoˇrá- dány do vrstev a každá vyšší vrstva poskytuje další funkˇcnostnavíc k pˇredchozí. Backend zajišt’uje klíˇcovounízkoúrovˇnovoufunkcionalitu jako manipulaci s archivy, samotnou instalaci balík ˚u,ale též správu data- báze balík ˚u.Dependency solver doplˇnujefunkˇcnostbackendu pˇre- devším o ˇrešení a doplˇnovánízávislostí a stažení softwaru ze vzdá- lených úložišt’. Koncovému uživateli je pak vhodné nabídnout gra- fické rozhraní snadné procházení a manipulaci se softwarem. Obrázek 1.1: Obecné schéma systému pro správu software 5 1. ARCHITEKTURASYSTÉMU˚ PRO SPRÁVU SOFTWARE 1.1 Historie software management systém ˚u Z historie víme, že první GNU/Linux distribuce tento nástroj po- strádaly. Až v roce 1994 byl vytvoˇrenBOGUS Linux[1], který mˇel nástroj umožˇnujícíinstalaci balík ˚uz instalaˇcníchCD. Vzdálené úlo- žištˇebylo prvnˇeimplementováno do nástroje Advance Package Tool (APT) v Debian GNU/Linuxu v roce 1998[2]. V dnešní dobˇeexistuje nˇekolikimplementací jako Aptitude, Yum, Pacman, ZYpp a jiné. 6 Kapitola 2 Dependency solvery a problém ˇrešenízávis- lostí „Základem každé aplikace pro správu software je ˇrešenízávislostí.“ Podle pravidla „rozdˇel& panuj“ se software v unixových systé- mech rozkládá na ˇcástis co nejmenší funkˇcnost.Každý kousek soft- waru popisuje funkˇcnost,kterou poskytuje a také tu, kterou od ji- ných vyžaduje jako tzv. závislost. Úkolem dependency solveru (de- psolveru) je hledat a kontrolovat vztahy mezi jednotlivými balíky. Je nˇekolikvˇecí,které musí depsolver zajišt’ovat. Vykonat poža- davky na pˇridáníˇciodebrání softwaru dle požadavku uživatele, udr- žovat systém v konzistentním stavu a optimalizovat instalaˇcnípro- cesu (snaha je, aby se odstranilo co nejménˇebalík ˚u).Ve své podstatˇe dependency solver rozpozná, stáhne a nainstaluje tranzitivní uzávˇer stromu závislostí daného balíku. 2.1 Typy závislostí Do nedávné doby se používaly pouze silné závislosti, ale u nˇekte- rých novˇejšíchdistribucí se v nedávné dobˇezaˇcalypoužívat i zá- vislosti slabé, které jsou spíše doporuˇcujícía na výslednou fukˇcnost programu nemají, na rozdíl od tˇechsilných, takový vliv. Co pˇresnˇe 7 2. DEPENDENCYSOLVERYAPROBLÉM REŠEN͡ ZÁVISLOSTÍ jednotlivé závislosti znamenají vysvˇetlímdále. Závislosti mohou být doplnˇenyrelaˇcnímioperátory (>,<,<=, atd), pomocí kterých lze spe- cifikovat konkrétní verzi knihovny, ˇcirozsah verzí, ve které je vyža- dovaná funkˇcnostobsažena. 2.1.1 Silné (Strong) Requires – absolutní závislosti, všechny požadavky musí být spl- nˇeny. Je velice pravdˇepodobné,že bez nich nebude program v ˚ubec fungovat. Napˇr.:Balík firefox vyžaduje xulrunner >= 1.9.2.3-1, ale též libc.so.6(). Provides – funkcionalita, kterou tento balík poskytuje. Tyto jsou spo- jovány s absolutními závislostmi (requires) pˇriˇrešenízávislostí. Napˇr.:Balík firefox-3.6.3 poskytuje libbrowsercomps.so()(64bit), ale též firefox = 3.6.3-4. Pokud tedy nˇejakýbalík potˇrebujefirefox >= 3.6.3 porovná se verze s touto a vrátí se výsledek. Conflicts – balíky, které nemohou být nainstalovány pokud jiný po- skytuje danou funkˇcnost. Napˇr.:firefox-3.6.3 conflicts xulrunner >= 1.9.2.4. Obsoletes – pokud je tento balík nainstalován, obsoletes balíky bu- dou odinstalovány jako zastaralé. Napˇr.:firefox obsoletes mozilla <= 37:1.7.13 8 2. DEPENDENCYSOLVERYAPROBLÉM REŠEN͡ ZÁVISLOSTÍ Jak je vidˇetz pˇríklad˚u,závislosti mohou být doplnˇenynejen relaˇc- ními operátory a edicí, ale též architekturou, která je však vˇetšinou uvedena již ve jménˇepˇr.libm.so.6()(64bit). 2.1.2 Slabé (Weak nˇekdytéž Soft) Recommends – je to obdoba absolutních závislostí, ale pokud dep- solver její potˇrebynem ˚užesplnit, je zahozena, aniž by se resoluce nedokonˇcila.Dobrým pˇríklademzde mohou být napˇr.jazykové ba- líky u kanceláˇrskýchaplikací ˇcipodpora pro ménˇerozšíˇrenéarchivy u program ˚u Existují i nˇekterédalší typy slabých závislostí, napˇr.Suggests, ty budou popsány v následující kapitole. 9 Kapitola 3 Analýza a porovnání stávajících solver ˚u Na následujících nˇekolikastranách rozeberu specifika implementací ˇrešenízávislostí u nejrozšíˇrenˇejšíchdistribucí. 3.1 SUSE Po akvizici Ximianu Novellem byly pod jednou stˇrechoudva balí- kovací systémy, tudíž pˇrišlainiciativa vzít ze stávajících to nejlepší a navrhnout zbrusu nový nástroj. Tím se stal ZYpp Nás ovšem zajímá pˇredevšímjeho dependency solver, který se jmenuje libZYpp.[7] Pˇredtˇremilety zapoˇcalvývoj nového dependency solveru, po nˇe- kolika mˇesícíchvývoje a pˇrepsáníMiniSatu prošel nový solver vˇet- šinou test ˚ua mohl být nasazen. Tento dependency solver ˇrešízávis- losti pˇrevodemna problém splnitelnosti klauzulí alias SAT. 3.1.1 Definice problém splnitelnosti klauzulí Problém spoˇcíváv nalezení ohodnocení všech promˇennýchz for- mule pomocí hodnot TRUE/FALSE tak, že výsledek je TRUE. Tento problém je NP-úplný. SAT problémy byly poprvé popsány S. Coo- kem [9] Napˇr.:(a | b | c) & (-c) & (-a | c) = TRUE, pak 10 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ a = FALSE, b = TRUE, c = FALSE 3.1.2 Tvoˇrenípravidel Requires – Balík A vyžaduje balík B, které poskytují B1 a B2. (-A | B1 | B2) – bud’ není A nainstalováno a nebo jeden z B1, B2 je nainstalován. Conflicts a Obsoletes – A koliduje s B, který poskytovaným B1 a B2. (-A | -B1), (-A | -B2) – bud’ není A nainstalováno a nebo B1 a B2 nejsou nainstalovány. Install – Požadujeme instalaci A. A – Balík A musí být nainstalován. Remove – Požadujeme odstranˇeníA. -A – Balík A nem ˚užebýt nainstalován (bude odinstalován). 3.1.3 Výhody a nevýhody libzypp Výhody jsou následující: 1. úplnost1 – pokud existuje ˇrešení,solver by ho mˇelnajít, 2. rychlost – v porovnání s oblastmi kde je SAT solver nasazován je složitost depsolvingu celkem nízká, což vede k celkovˇedob- rým výsledk ˚um, 1. v oblasti algoritm ˚use úplnost (completeness) nazývá schopnost nalézt ˇrešení, pokud takové existuje a pokud ne, oznámit, že žádné ˇrešeníneexistuje[6] 11 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ 3. pˇrehlednostkódu – algoritmus pro ˇrešenízávislostí má nˇekolik stovek ˇrádk˚ukódu, 4. dobˇrezmapovaný problém – existence kvalitních a volnˇedo- stupných implementací (chaff, minisat), 5. podpora soft dependencí, a nevýhody jsou tyto: 1. nemožnost odstranit balík s danou architekturou4.2.1 a 2. nekompatibilita s jinými distribucemi, zatím pˇrílišspecifický pro distribuci SUSE. 3.2 Debian Debian dnes používá program APT[2], což je frontend nad balíˇc- kovacím systémem dpkg. Jak jsem již uvedl, Debian vytvoˇrilsolver jako jeden z prvních již v roce 1993. Dalo by se ˇríci,že jeden z pilíˇr˚u úspˇechuDebianu je právˇetento systém. Dpkg je pro .deb balíky tím, ˇcímrpm (ˇcirpmlib) pro rpm balíky. Zprostˇredkováváprogramu APT informace o závislostech jednotlivých balík ˚u,které APT dále zpraco- vává. 3.2.1 Algoritmus Instalace balíku probíhá následovnˇe: 12 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ 1. zjistí se závislosti balíku, 2. pokusí se instalovat chybˇejícízávislosti jednu po druhé v po- ˇradíjak jsou uvedeny v balíku, 3. pro každou závislost se nainstaluje subzávislost nejvyšší do- stupné verze, 4. pokud je konflikt s závislostí, která by mˇelabýt instalovaná, zruší se její instalace, 5. pokud je konflikt s již nainstalovanou závislostí, instalátor se zeptá zda chce být balík ji poskytující odstranˇen[5]. 3.2.2 Výhody a nevýhody APT Výhody jsou následující: 1. rychlost, 2. možnost využít deb i rpm balík ˚u(rpmlib ˇcidpkg), a nevýhody jsou tyto: 1. neúplnost - ne vždy najde ˇrešení,i když existuje, 2. nemožnost koexistence více balík ˚ustejné verze. 13 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ 3.3 Fedora Systém pro správu balík ˚u,který používá Fedora se jmenuje YUM, název p ˚uvodnˇepochází z Yellow Dog Linuxu. Pracuje s rpm balíky a ke komunikaci se svým rpm backendem používá jeho Pythoní API a je v tomto jazyce, vˇcetnˇedependency solveru, celý napsán. Depsol- veru z YUMu bych se rád vˇenovalhloubˇeji,protože se s mou imple- mentací v základech podobají. Depsolver pracuje s rpmlib, která poskytuje informace o požadav- cích a závislostech avšak pouze do prvního levelu, tzn. že depsolver musí své dotazy opakovat do té doby, dokud nenarazí na balíky bez závislostí. 3.3.1 Repositáˇra jeho formát Repositáˇrejsou lokální ˇcivzdálená úložištˇemetadat. Jedná se o xml soubor, který obsahuje vše potˇrebnépro balíkovací systémy, i jejich dependency solvery. Tento formát, který byl navržen na Duke University v Severní Karolínˇe,jako obecný repositáˇrpro balíkovací systémy, se stal brzy standardem a je používán mnoha distribucemi založenými na rpm (SUSE, Mandriva, atd). Hlavní soubory repomd.xml – metadata repositáˇre,velmi malý soubor, který odka- zuje na další soubory repositáˇre.Obsahuje ˇcasovárazítka a kontrolní souˇcty. primary.xml.gz – nejd ˚uležitˇejšíˇcástrepositáˇrepro depsolving; list balík ˚us jejich závislostmi a požadavky, ale též popis ˇcivelikost na- instalovaného balíku. 14 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ filelists.xml.gz – seznam soubor ˚ukteré jednotlivé balíky obsahují. other.xml.gz – obsahuje seznamy zmˇen(changelogs). Distribuce mohou používat i své vlastní xml soubory, staˇcíje jen uvést v repomd.xml. Napˇríkladjiž zmiˇnovanéSUSE používá suse- data.xml, kde se nacházejí napˇrflag Protože se jedná o databázi, pˇrešlose u YUMu po nˇekolikaletech používání dotaz ˚upˇresxml parser na sqlite databáze, což pˇrineslo pˇredevšímrychlejší vyhledávání. Repositáˇrz rpm balík ˚ui jeho sqlite databáze jsou tvoˇrenynástrojem createrepo. 3.3.2 Algoritmus Instalace balíku pomocí nástroje YUM probíhá takto: 1. zkontrolují se závislosti balíku, pokusí se jednu po druhé nain- stalovat chybˇející, 2. pro každou závislost se snaží nainstalovat subzávislost nejvyšší dostupné verze, 3. pokud je konflikt v závislosti, která je navržena pro instalaci, pak nastane chyba, 4. pokud je konflikt se závislostí, která je již nainstalována, tak také nastane chyba[5]. 15 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ 3.3.3 Výhody a nevýhody depsolveru z YUMu Výhoda je tato: 1. sqlite formát repositáˇre, a nevýhody jsou tyto: 1. není úplný – nenalezne vždy ˇrešeníi když existuje viz sekce Testy4, 2. pamˇet’ová nároˇcnost– napˇríkladpˇripovýšení celé distribuce se m ˚užespotˇrebapamˇetivyšplhat i na nˇekolikstovek MiB, což m ˚užebýt pˇredevšímu starších poˇcítaˇc˚uproblém, 3. ˇcasovánároˇcnost– pokud není ˇrešenípˇrímoˇcaréa vyskytují se konflikty ˇciobsoletes, m ˚uževyˇrešenítrvat i nˇekolikdesítek vteˇrin. 3.4 Gentoo Protože je Gentoo kompilovaný systém2, je celý koncept závis- lostí trochu jiný. Systém pro správu balík ˚use nazývá Portage a je inspirován balíkovacími systémy z freeBSD. Používá se nˇekolikr ˚uz- ných typ ˚uzávislostí - build, runtime, post-merge, system[4]. Napˇrí- klad post-merge, které se provádˇejíaž po samotné instalaci jsou ja- kousi obdobou rpm skript ˚uPOSTIN, POSTUN, PREIN, které však s 2. Pˇrevážnáˇcástsoftware se pˇrednainstalováním kompiluje ze zdrojových kód ˚u podle uživatelových nastavení. 16 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ ˇrešenímzávislostí nemají nic spoleˇcného(u rpm jsou spíše konfigu- raˇcnímiskripty). Další zmˇenaje v kategorizaci aplikací, což by mˇelo mít za následek urychlení vyhledávání i snadnˇejšíorientaci. Používají se tyto typy závislostí: Klasická (Basic) – specifikuje pouze aplikaci, napˇr.:app-misc/foo. Na verzi (Version) – m ˚uže,ale nemusí obsahovat relaˇcní operátor, napˇr.:>=app-misc/foo-1.23. Rozsahová (Ranged) – splˇnujekterákoliv edice dané verze, napˇr.: =x11-libs/gtk+-2*. Slotová (Slot) – pokud se balíky liší ˇcíslemv názvu dá se použít slot, napˇr.:x11-libs/qt:3. Blokátor (Blocker) – stejné s obsoletes. Mohou, ale nemusí specifi- kovat verzi balíku, napˇr.: Další specialitou v Portage jsou tzv. Use-flagy. Pomocí nich m ˚u- žete specifikovat kompilaˇcnívolby balík ˚u,tudíž i závislosti, které budou pro kompilaci ˇcispuštˇenítˇreba.Tyto mohou být uloženy v konfiguraˇcnímsouboru, a nebo specifikovány pˇrikaždé instalaci, po- pˇrípadˇev kombinaci. Napˇr.:python? ( dev-lang/python) . Pokud se tedy zapne use-flag python, musí se též zahrnout do re- zoluce. Pˇriˇrešenízávislostí Portage bud’ prochází kompletnˇestrom portage, nebo prochází jednotlivé ebuild soubory3 a díky velikému 3. Ebuild soubor obsahuje všechny informace nutné k instalaci balíku. Je to ob- 17 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ množství diskových operací je tato metoda velice ˇcasovˇenároˇcnáa tudíž neefektivní. Pro snížení poˇctudiskových operací a zrychlení vyhledávání je použita cache ve formˇesqlite databáze. Tato data- báze je pˇrikaždé aktualizaci portage stromu stažena ze serveru, ale je možné ji generovat i ruˇcnˇe. 3.4.1 Algoritmus Instalace balíku probíhá následovnˇe: 1. zjistí se všechny závislosti daného balíku, 2. zkusí se nainstalovat závislosti jedna po druhé v takovém po- ˇradí,jako jsou uvedeny z ebuild souboru, jestliže m ˚užebýt zá- vislost povýšena, uˇciˇntak, 3. pro každou závislost nainstaluj její závislosti s nejvyšší možnou verzí, 4. pokud má závislost konflikt se závislostí, která by mˇelabýt in- stalována, zruš tuto instalaci, 5. pokud má závislost konflikt s již nainstalovaným balíkem, ukonˇci výpoˇcetzávislostí[5]. 3.4.2 Výhody a nevýhody Portage Výhodami jsou: 1. nejvˇetšívariabilita ze systém ˚uuvedených v této kapitole, 2. možnost ˇrešitproblémy resoluce odebráním „flagu”, doba spec filu u RPM. 18 3. ANALÝZA A POROVNÁNÍ STÁVAJÍCÍCH SOLVERU˚ a nevýhody jsou tyto: 1. není úplný, 2. velice Gentoo specifický, nelze ho použít s rpm ˇcideb balíky. 19 Kapitola 4 Testy V této kapitole je zobrazeno nˇekoliktest ˚u,které by mˇelypˇresnˇeji ukázat vlastnosti naznaˇcenév pˇrehledujednotlivých distribucí. 4.1 Car test Pˇripraviljsem sadu rpm balík ˚us danými závislostmi, jak jsou nazna- ˇcenyna obrázku. Tento test má ukázat úplnost tj. schopnost nalézt ˇrešení,pokud takové existuje. Test je také schopen ukázat kvalitu da- ného ˇrešení.Jedna ze základních vlastností systém ˚upro správu soft- ware je spravovat „aktuální” sadu balík ˚una daném systému, proto nás zajímá nejen rychlost, ale též kvalita nabízeného ˇrešení.Protože nˇekterénástroje v tomto testu selhaly, provedl jsem ještˇedruhý test, kde jsem nejdˇrívenainstaloval balík window-1 ruˇcnˇea až poté spus- til instalaci balíku car. 20 4. TESTY Obrázek 4.1: graf závislostí a konflikt ˚uv testovacím repositáˇri Tento repositáˇrobsahuje vnoˇrenýkonflikt mezi glass verze 2 a tyre verze 2 a má jedno optimální ˇrešení- Obrázek 4.2 Obrázek 4.2 optimální ˇrešení 21 4. TESTY 4.1.1 ZYpper [root@localhost /]# zypper install car: Probíhá rešeníˇ závislostí balíck˚u...ˇ Nucené vyrešení:ˇ Ne Následující NOVÉ balíckyˇ budou nainstalovány: car 1-0 door 2-0 engine 2-0 glass 1-0 tyre 2-0 wheel 3-0 window 2-0 7 nové balíckyˇ k instalaci. Z tˇechtovýsledk ˚uje patrné, že libzypp solver došel k optimál- nímu ˇrešenítudíž ho lze oznaˇcitza úplný. 4.1.2 YUM po spuštˇení [root@localhost /]# yum install car: Rešíˇ se závislosti ---> Balícekˇ car.noarch 0:1-0 nastaven k aktualizaci --> Zpracování závislosti: engine pro balícek:ˇ car-1-0.noarch 22 4. TESTY --> Zpracování závislosti: wheel pro balícek:ˇ car-1-0.noarch --> Zpracování závislosti: door pro balícek:ˇ car-1-0.noarch ---> Balícekˇ door.noarch 0:2-0 nastaven k aktualizaci --> Zpracování závislosti: window pro balícek:ˇ door-2-0.noarch ---> Balícekˇ engine.noarch 0:2-0 nastaven k aktualizaci ---> Balícekˇ wheel.noarch 0:3-0 nastaven k aktualizaci --> Zpracování závislosti: tyre pro balícek:ˇ wheel-3-0.noarch ---> Balícekˇ tyre.noarch 0:2-0 nastaven k aktualizaci ---> Balícekˇ window.noarch 0:2-0 nastaven k aktualizaci --> Zpracování závislosti: glass pro balícek:ˇ window-2-0.noarch ---> Balícekˇ glass.noarch 0:2-0 nastaven k aktualizaci --> Zpracování konfliktu: glass-2-0.noarch je v konfliktu s tyre = 2 --> Zpracování konfliktu: tyre-2-0.noarch je v konfliktu s glass = 2 --> Rešeníˇ závislostí dokoncenoˇ Chyba: tyre conflicts with glass Chyba: glass conflicts with tyre Zde je vidˇet,jak už jsem uvedl výše, že yum není úplný, protože nenalezl ˇrešení,aˇctakové zˇrejmˇeexistuje. YUM nenalezl žádné ˇre- šení, ani sub-optimální, které zˇrejmˇetéž existuje. Pˇriinstalaci balíku window-1 se jako závislost nainstaloval glass-1 a tudíž i následná instalace car probˇehlapodle oˇcekávánív poˇrádku. 23 4. TESTY 4.1.3 APT Apt v tomto testu nedopadl v ˚ubecdobˇre.Nevím zda je to zp ˚uso- beno jen jeho rpm mutací, která operuje nad rpm, ale výsledky jsou následující: [root@localhost /]# apt-get install car Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requestedan impossible situation or that some of the repositories in use are in an inconsistent state at the moment. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: car: Depends: wheel E: Broken packages V testu úplnosti dopadl obdobnˇejako yum, nenašel ˇrešení.Pˇri pokusu APT pˇrirezoluci pomoci instalací balíku window-1 došlo ovšem k fatálnímu selhání. Apt-get zahlásil nedostupnost balíku glass- 1, který v repositáˇrije. Zde je vidˇetjeden z rys ˚udepsolving algoritmu a to ten, že se hledá nejvyšší možná verze, což v tomto pˇrípadˇenení dobˇre.Po ruˇcníinstalaci glass-1 a window-1 již instalace balíku car probˇehlav poˇrádku. 24 4. TESTY 4.1.4 Moje implementace Arch: noarch Resolving Dependencies: wheel-3-0.noarch tyre-1-0.noarch door-1-0.noarch car-1-0.noarch Done! Packages for installation: 4 Packages for removal: 0 Moje implementaci sice ˇrešenínašla, ale bohužel ne optimální. Protože nevybrala nejvyšší možné verze, tak se v ˚ubecnedostala ke konflikt ˚um.Kde by dopadla podobnˇejako YUM ˇciAPT. Zkusil jsem alespoˇninstalaci window-1 a tam solver našel ˇrešenía nainstaloval ho spoleˇcnˇes glass-1. 4.2 Test odstranˇeníglibc Další test je zamˇeˇrenpˇredevšímna ˇcasovounároˇcnostdepsolvingu. Na testovacím systému1 se 1781 balíky jsem provedl dependency solving pˇriodstranˇeníjedné ze základních knihoven – glibc. Balíky jsou nejen i686 architektury, ale i x86_64. Provedl jsem jak odstra- nˇeníglibc.i686, tak odstranˇeníglibc.x86_64. Výsledky jsou uvedeny v pˇrehledu. 1. Intel Core 2 Duo T7100 @ 1.8 GHz 25 4. TESTY 4.2.1 ZYpper [root@localhost /]# time zypper remove glibc.i686 1 balícekˇ k aktualizaci, 1569 k odstranení.ˇ Celková stahovaná velikost: 16,0 KiB. Po operaci bude uvolnenoˇ 3,9 GiB. Pokracovat?ˇ [y/n/p/?] (y): real 0m6.481s user 0m6.229s sys 0m0.245s [root@localhost /]# time zypper remove glibc.x86_64 1 balícekˇ k aktualizaci, 1569 k odstranení.ˇ Celková stahovaná velikost: 16,0 KiB. Po operaci bude uvolnenoˇ 3,9 GiB. Pokracovat?ˇ [y/n/p/?] (y): real 0m6.481s user 0m6.229s sys 0m0.245s ZYpper vyˇrešilzávislosti v nejkratším ˇcasetohoto testu. Poˇcetba- lík ˚uje též nejnižší ze všech testovaných solver ˚u.Jediný problém byl s odinstalací glibc ve verzi i686, kde solver, pˇrestožebyla architektura specifikována, ˇrešilna závislosti na defaultní x86_64. Tato chyba je pravdˇepodobnˇezp ˚usobenaportem na Fedoru, na které test probí- hal. 26 4. TESTY 4.2.2 YUM [root@localhost /]# time yum remove glibc.i686 Odstraneníˇ 109 balícku/˚uˇ Reinstalace 0 balícku/˚uˇ Snížení verze 0 balícku/˚u\ˇ V porádkuˇ [a/N]: Ukoncenoˇ na príkazˇ uživatele Hotovo! real 0m3.665s user 0m3.369s sys 0m0.237s [root@localhost /]# time yum remove glibc.x86_64 Odstraneníˇ 1676 balícku/˚uˇ Reinstalace 0 balícku/˚uˇ Snížení verze 0 balícku/˚uˇ V porádkuˇ [a/N]: Ukoncenoˇ na príkazˇ uživatele Hotovo! real 0m18.842s user 0m15.716s sys 0m1.495s Yum v tomto testu z ˇcasovéhohlediska dopadl nejh ˚uˇre.Z namˇe- ˇrenýchˇcas˚usice m ˚užemeodeˇcístzhruba 2 vteˇrinybˇehupˇredsamot- ným depsolvingem, ale i tak je oproti konkurenci více jak 2x poma- lejší. Z pohledu odinstalovávaných balík ˚utéž nedopadl podle oˇce- kávání, protože k balík ˚umarchitektury x86_64 pˇridali glibc.i686 a tím navýšil poˇcetodstranˇenýchaplikací o poˇcetodstranˇenýchz 32 bitového testu. 27 4. TESTY 4.2.3 APT [root@localhost /]# time apt-get remove glibc.32bit 0 upgraded, 0 newly installed, 109 removed and 29 not upgraded. Need to get 0B of archives. After unpacking 221MB disk space will be freed. You are about to do something potentially harmful To continue type in the phrase ’Yes, do as I say!’ ?] Abort. real 0m3.095s user 0m2.928s sys 0m0.160s [root@localhost /]# time apt-get remove glibc 0 upgraded, 0 newly installed, 1677 removed and 4 not upgraded. Need to get 0B of archives. After unpacking 4409MB disk space will be freed. You are about to do something potentially harmful To continue type in the phrase ’Yes, do as I say!’ ?] Abort. real 0m7.662s user 0m7.458s sys 0m0.164s APT se v ˇcasovénároˇcnostiumístil tˇesnˇeza ZYpperem. Z tohoto pohledu jistˇepozitivní výsledek, ale v poˇctuodstranˇenýchbalík ˚u se chová stejnˇejako yum. K 1569 balík ˚um,které vypoˇcetlZYpper pˇridávádalších 108, které jsou z 32bitové architektury a které není nutno, pˇriodstraˇnováníglibc.x86_64, odstraˇnovat. 28 4. TESTY 4.2.4 Moje implementace [root@localhost /]# time ./depends.py glibc.i686 2 Arch: i686 Resolving Dependencies: Done! Packages for installation: 0 Packages for removal: 109 1465 real 0m1.275s user 0m1.181s sys 0m0.093s [root@localhost /]# time ./depends.py glibc.x86_64 2 Arch: x86_64 Resolving Dependencies: Done! Packages for installation: 0 Packages for removal: 1580 real 0m13.939s user 0m12.700s sys 0m1.237s 29 4. TESTY Jak je vidˇetz výsledk ˚utest ˚uu mojí implementace, u 64 bitové ar- chitektury je ˇcaso nˇecokratší než u yumu (ten byl ovšem použit jako celek, tudíž tam došlo k urˇcitémuzpoždˇení).Poˇcetbalík ˚use témˇeˇr vyrovnal ˇrešeníZYpperu, nejsou zde zahrnuty balíky jiných archi- tektur. U 32 bitové architektury (tam kde se test podaˇrilspustit) mají všechny solvery stejné množství balík ˚u– 109, ˇcasmé implementace je lepší zhruba o dvˇevteˇrinyod ostatních solver ˚u.Jak jsem již uvedl, m ˚ujsolver je pouze solver, kdežto u ostatních test ˚use spouští celá aplikace, což m ˚užepˇrinéstzpoždˇenícca 2 vteˇriny. I tak je ovšem do- sažený výsledek velice dobrý. Výsledky jsou pˇrehlednˇezachyceny v grafu 8.4. Testováno bylo na Fedoˇre12, Hewlett-Packard 6510b, Intel Core 2 Duo CPU T7100, 1,8 GHz, 4GiB RAM. Graf 8.4: Výsledky mˇeˇrenípˇrirezoluci odstranˇeníglibc 30 4. TESTY 4.3 Test pamˇet’ové nároˇcnosti Test pamˇet’ové nároˇcnostibyl opˇetproveden na operaci odstranˇení glibc.x86_64. Výsledky jsou zachyceny v grafu 9.4. YUM dostál své povˇestia skonˇcils více jak šestinásobnou spotˇreboupamˇetidaleko za ostatními. V tomto testu má implementace dosáhla pouze tˇreti- nové spotˇrebyYUMu. Graf 9.1: Výsledky mˇeˇrenípamˇet’ové nároˇcnosti Z tˇechtovýsledk ˚uje patrná naprostá nepoužitelnost YUMu na starých systémech s ménˇenež 256 MiB RAM. 31 Kapitola 5 Vlastní implementace V této kapitole bych se chtˇelvˇenovatdetail ˚ummého depsolveru. Jako implementaˇcníjazyk jsem zvolil Python, nebot’ jak rpm, z jehož databáze jsou brány informace o nainstalovaných balících, tak sq- lite3, v jehož formátu jsou databáze v repositáˇrích,mají svá API pro tento jazyk. Python je též objektovˇeorientovaný a obsahuje pokroˇcilé struktury pro hashování, což znaˇcnˇeusnadnilo implementaci. 5.1 Architektura Dependency solver obsahuje FIFO frontu Q, ze které se postupnˇevy- bírají úkoly a ty se zpracovávají. Zpracování probíhá tak dlouho, do- kud není fronta prázdná – resoluce probˇehlaúspˇešnˇe,a nebo dokud solver nezahlásí chybu. Navrženou architekturu asi nejlépe charak- terizuje následující obrázek: 32 5. VLASTNÍ IMPLEMENTACE Obrázek 9.1 Fronta Q zpracovávající Qtask akce 33 5. VLASTNÍ IMPLEMENTACE 5.2 Hlavní komponenty Program má tyto hlavní komponenty: 5.2.1 Fronta Q Fronta Q poskytuje First-In-First-Out frontu pro Qtask položky 5.2.2 Process proces je hlavní ústrojí celého dependency solveru. Bere si po- ložky z fronty Q a zpracovává je. Zpracování se dˇejepo jednom, nebot’ každá z nich vyžaduje konkrétní obsluhu. Zpracování Qtask položky m ˚uževést k vytvoˇrenía zaˇrazenídalších (i jiných typ ˚u)do fronty Q. Typickým pˇríklademje, když QtaskInstall (požadavek na instalaci balíku) vyžaduje nˇejakézávislosti. Zpracování pokraˇcuje až do vyprázdnˇenícelé fronty, nebo do ohlášení chyby. 5.2.3 Qtask Qtask je meta tˇrída k jednotlivým úkol ˚um,které se liší podle zpracování na QtaskInstall, QtaskRemove, QtaskRequire a Qtask- Conflict QtaskInstall instalace ˇciupdate balíku pokud je nainstalován balík stejného jména, místo instalace se provádí update, který vytvoˇrípožadavek na odinstalování staré verze. Zpracování probíhá následujícím zp ˚usobem: • je balík stejného jména nainstalován? pokud ano a je dostupný update, vytvoˇrpožadavek na odinstalování starého 34 5. VLASTNÍ IMPLEMENTACE • zjisti všechny závislosti daného balíku a vytvoˇrpožadavek na doplnˇení(QtaskRequire) • zjisti konflikty a vytvoˇrpožadavek na vyˇrešení(QtaskConflict) QtaskRemove odstranˇeníbalíku • zjisti všechny závislosti, které budou porušeny • pro každou závislost zjisti, jestli je stále nˇekdo,kdo ji potˇrebuje, pokud ano mohlo by dojít k porušení závislostí: – pokud je nˇejakýdalší balík, který danou závislost posky- tuje (závislost je uspokojena), jsme hotovi – pokud ji nikdo neposkytuje, vytvoˇrpožadavek na její in- stalaci (QtaskRequire) QtaskRequire doplnˇeníchybˇejícízávislosti • pokud má závislost rodiˇce(to znamená, že je jím požadována jako nesplnˇená),který není oznaˇcenke smazání, pokus se ji na- instalovat – pokud se to nepovede, zkus povýšit rodiˇcenebo – smaž rodiˇce– uživateli bude toto smazání oznámeno 35 5. VLASTNÍ IMPLEMENTACE • pokud je závislost nalezena, nainstaluj ji (vytvoˇrQtaskInstall) QtaskConflict vyˇrešeníkonfliktu • zjisti kdo potˇrebujebalík který je nainstalován a je v konfliktu, pokud nikdo, odinstaluj jej (QtaskRemove) • pokud je konfliktní balík potˇreba,ohlas chybu. 5.3 Databáze a rozhraní Implementace používá pouze rozhraní k rpm. Z toho plyne použití dvou druh ˚udatabází. BsdDB[8], kterou používá rpm pro ukládání informací o nainstalovaných balících a SQLite3[10], která je použita v repositáˇrích,kde se nacházejí informace o dostupných balících. Rpmlib poskytuje rozhraní k pˇrístupudo své databáze, lze se do- tazovat na jméno, závislosti, jejich verze, konflikty a ještˇenˇekteré další položky (adresáˇre,kontrolní souˇcty, atd.) které však m ˚ujsol- ver nevyužívá. Dotazy do tˇechtodatabází používají diskové operace, proto je lze oznaˇcitza drahé. SQLite databáze repositáˇrebalík ˚uje velice pˇrehlednˇevytvoˇrená a dá se v ní pohodlnˇevyhledávat. Každý balík má své id (PkgKey), podle kterého se dají velice pohodlnˇevyhledávat závislosti jednotli- vých balík ˚u.Ovšem i toto jsou diskové operace, tudíž kritické místo celého ˇrešenízávislostí (podrobnosti o ˇcasecha množstvích jednotli- vých dotaz ˚uv sekci Optimalizace). 5.4 Optimalizace Navržená architektura aplikace využívá ˇcastédotazy do databází, jak už jsem pˇredeslal,tyto operace jsou velmi drahé. Po napsání apli- 36 5. VLASTNÍ IMPLEMENTACE kace trvala resoluce na cca 1600 balících pˇres20 vteˇrin.Tento ˇcasje pro dependency solving pˇrílišdlouhý. Za pomoci pythoního cPro- file profileru[11] jsem zjistil, že napˇríklad13 000 volání metody who- Provides()1 zabere pˇres5.5 vteˇriny. Ten samý poˇcetvolání metody whoProvides() zabere dokonce více jak 8 vteˇrin.Na konci každé me- tody jsem tedy uložil výsledek do slovníku s klíˇcem,což byl hash jména závislosti a na zaˇcátkutˇechtofunkcí se dotazuji na existenci výsledku. Tato optimalizace ušetˇrilapˇres3 vteˇriny. Tento postup jsem uplatnil i pˇriporovnávání objekt ˚uv install a Qtask objekt ˚u,ˇcímžjsem výslednou dobu snížil ke 14 vteˇrinám.Ob- jekty typu Qtask bud’ nesou informace o jménu balíku, spolu s jeho verzí, vydáním a architekturou, nebo závislost, která má podobné atributy (místo architektury má relaˇcníoperátor). Tudíž porovnání tˇechtoobjekt ˚uspoˇcíváv porovnání všech položek, což je daleko ná- roˇcnˇejšínež porovnání hashe. 1. pˇrijiž zmínˇenémtestu odstranˇeníglibc.x86_64 37 Kapitola 6 Závˇer Z provedeních test ˚uplynou následující závˇery. 6.1 Casovᡠnároˇcnost Pˇrimalých objemech instalovaných/odebíraných balík ˚u(kolem 100) je má implementace velice rychlá, s nar ˚ustajícímpoˇctembalík ˚uv re- soluci ˇcasovánároˇcnostnar ˚ustá.Nenar ˚ustáovšem exponenciálnˇe, ani polynomiálnˇe,ale lineárnˇe1, což je u toho typu problému rela- tivnˇedobré. V porovnání s YUMem je resoluce dokonce rychlejší a v nˇekterýchpˇrípadechi pˇresnˇejší(viz test odinstalace glibc). Ovšem jsou dostupné implementace, které jsou schopny provést velice slo- žitou resoluci v poloviˇcnímˇcases výbornou pˇresností(libzypp). Jako hlavní problém mé implementace vidím pˇrílišmnoho dotaz ˚udo da- tabází. Z patnácti vteˇrinje témˇeˇrdvanáct zabráno ˇctenímdatabází. Zde se též nabízí otázka, zda by databáze nemohla být navržena vhodnˇeji.Jako jedno z možných zlepšení vidím v zavedení verze pˇrímodo jména závislosti2, ˇcímžse poˇcetzávislostí, které balík po- skytuje zvýší, ale pˇrirezoluci se nebude muset porovnávat. Otázka je, zda nepoužít jiný typ databáze. Další krok, který by mohl velice zkrátit ˇcasresoluce a je použití vláken. SQLite podporuje více vláknové ˇctení,tudíž tato možnost se 1. 100 balík ˚u~ 1 vteˇrina,1500 balík ˚u~ 15 vteˇrin 2. nˇekterébalíky (napˇrglibc) už to takto mají 38 6. ZÁVERˇ tu pˇrímonabízí, jakmile je ovšem databáze v pamˇeti,protože jinak ji opˇetbrzdí diskové operace. 6.2 Pˇresnost Jak jsme mohli vidˇetv Car testu, jediná skuteˇcnˇefunkˇcníimplemen- tace je lizypp. Se svou metodou pˇrevedeníproblému na SAT a schop- nosti nalézt více ˇrešení,otevírá rozhodnˇeprostor pro další zkoumání nasazení SAT solver ˚uk ˇrešenízávislostí. Nejh ˚uˇrev tomto testu do- padl APT, který nedokázal nalézt závislost, kterou poskytoval balík s nižší verzí. Moje implementace též není úplná (nenašla v mode- lové situaci optimální ˇrešení),ale tento problém pˇrekonatdokázala. Kvalita ˇrešeníje nejménˇestejnˇetak d ˚uležitájako ˇcasovánároˇcnost. 6.3 Pamˇet’ová nároˇcnost Aˇcbyl tento test velice krátký, je na nˇemjasnˇevidˇet,že i bez pa- mˇet’ových optimalizací lze udˇelatˇrešení,které si vystaˇcíse slabou polovinou konzumace YUMu. Tento výsledek byl trochu oˇcekáván, ménˇeuž velice nízké nároky APT. Zde se odkrývá d ˚uvod,proˇcvˇetšinastarších live distribucí byla založena na Debianu (Knoppix, Puppy, atd). V této oblasti se totiž každý volný megabyte pamˇetipoˇcítá. 39 6. ZÁVERˇ 6.4 Cíle V tomto posledním odstavci bych chtˇelpopsat kam se budou ubírat mé další kroky. Pˇredevšímbych se chtˇeldále zabývat ˇrešitelizalože- nými na SAT solverech, zde bude ovšem potˇrebaspecifikovat, jaké modifikace stávajících bude nutné udˇelataby byly co nejlépe splnˇeny nároky na ˇrešenízávislostí. Pokud by se podaˇrilonapsat tento solver v jazyce C, mohl by být použit pˇrímov rpm a YUM by se mohl ode- brat do zaslouženého d ˚uchodu. 40 Literatura [1] The BOGUS Linux Release Web Page – http://www.cs.unc.edu/~faith/bogus.html [2] APT - package handling utility – http://wiki.debian.org/apt- get [3] The MiniSat Page – http://minisat.se/ [4] Gentoo Development Guide – http://devmanual.gentoo.org/general- concepts/dependencies/index.html#implicit-system- dependency [5] EDOS - Environment for the development and Dis- tribution of Open Source software - Package ma- nagement meta-tools: survey and state of the art – http://www.mancoosi.org/edos/manager/ [6] Hunter, Geoffrey, Metalogic: An Introduction to the Metathe- ory of Standard First-Order Logic, University of California Pres, 1971 [7] LibZypp Project Page – http://svn.opensuse.org/autodocs/libzypp/HEAD/ [8] By Himanshu Yadava: The Berkeley DB Book, Apress, 2007, ISBN13: 978-1-59059-672-2 [9] S. A. Cook, The Complexity of Theorem Proving Procedures, in Proc. 3rd Ann. ACM Symp. on Theory of Computing, pp. 151–158, Association for Computing Machinery, 1971 [10] SQLite Web Page – http://www.sqlite.org [11] The Python Profilers – http://docs.python.org/library/profile.html 41
Metody Rešení Závislostí V Moderních Distribucích
