Packaging Tools Team, který se ve Fedoře stará o sadu nástrojů pro správu instalovaného softwaru, vykračuje v F18 novým směrem: Yum byl forknut a nový nástroj, který bude po několik příštích vydání Fedory vyvíjen paralelně s Yumem, se jmenuje DNF. V F18 je dostupný z hlavních repozitářů Fedory jako preview.
Popis nového balíčku jako feature naleznete zde: https://fedoraproject.org/wiki/Features/DNF.
Důvodů pro fork bylo několik, ale hlavním z nich je problémová udržovatelnost Yumu, nedosažitelná unifikace resolverů závislostí mezi Yumem a RPM a citelná nemožnost použít pro psaní rozšíření balíčkovacího stacku jiný jazyk než Python.
DNF není zdaleka hotové: jedná se spíš o ukázku pro experimentátory, kterým nevadí, že více exotické příkazy známé z Yumu zatím chybí. Živý seznam nejzásadnějších nedostatků oproti Yumu otevřel James Antill v Red Hat bugzille. Seznam příkazů, které podporované jsou, je udržován v dokumentaci DNF, po instalaci balíčku je rovněž dostupný přes man dnf. Pokud se pro zkoušení odhodláte, což vřele doporučuji (a jako hlavní tvůrce DNF v to i doufám), a potážete se s uživatelskými nepříjemnostmi, neočekávaným chováním, nekompatibilitami nebo dokonce tracebacky, reportujte prosím svou zkušenost do bugzilly nebo se přijďte pobavit na IRC: irc.freenode.org, kanál #yum. Nová verze stacku DNF vychází nepravidelně zhruba každé dva týdny, oznámení se změnami vždy posílám na mailing list yum-devel.
Na rozdíl od Yumu je v DNF standardně povolen hodinový cronjob, který v případě potřeby synchronizuje prošlá metadata (dnf makecache). Měla by tak odpadnout většina čekání na stažení repozitářů, na které slýcháme v Packaging Tools Teamu tolik nářků.
Konečně, máte-li zájem proniknout do kódu a případně poslat patche, repozitář DNF je zde: https://github.com/akozumpl/dnf. Pro řešení závislostí mezi balíčky a rychlé prohledávání jejich metadat používá DNF novou knihovnu hawkey založenou na vynikajícím libsolvu od SUSE (v tomto případě se nejedná o fork ale o wrapper).
12. 11. 2012 at 10:21
Hm, trošku jsem se bál (od systemd a spol. na novinky koukám trošku s nedůvěrou), ale podle popisu mě nástroj zaujal. A dokopal k tomu, nainstalovat si konečně Alphu do virtuálu a testovat. Jo, jsem zvědavej. Díky za článek.
12. 11. 2012 at 10:31
Planuje sa aj funkcia ako yum history undo ID? Velmi uzitocna vec pri testovani roznych programov, odstrani vsetko aj zo zavislostami. Pripadne nieco ako apt-get autoremove?
12. 11. 2012 at 12:41
DNF bude 100% kompatibilní se všemi příkazy a funkcionalitami Yumu které jsou živé a používané. Pokud lidi používají history undo tak časem přijde—otevřením bugu to lze dokonce uspíšit.
14. 11. 2012 at 20:44
Díky za článek! Také mě to velice zaujalo. S yumem jsem spokojený, ale také mi vadí to čekání na načtení repos a celková poměrně pomalost (např. při opakovaném search) chtěl bych se zeptat, zda se zde plánují nějaké další urychlovací funkce. (Např při search, provides, history není řekl bych potřeba pokaždé natahovat moduly které nejsou potřeba (presto atd)
14. 11. 2012 at 22:28
Viděl jsem Alešovo demo DNF a řešilo se tam i porovnání rychlosti s Yumem. Byly operace, kde byl lehce rychlejší Yum, ale zase tam byly věci, u kterých bylo výrazně rychlejší DNF.
Zatím si myslím, že nejde jednoznačně říct, co z nich je rychlejší, ale osobně si myslím, že na tom bude lépe DNF. Navíc DNF má velký potenciál, optimalizace se ještě vůbec neřešila, prioritou je momentálně funkcionalita. Pokud se DNF v budoucnu trochu zoptimalizuje, tak na tom bude IMO mnohem lépe než Yum, co se týče rychlosti.
15. 11. 2012 at 09:23
Zdravím,
Problém rychlosti Yumu má dvě části: první (a řádově horší) je stahování metadat. Tento problém je potřeba řešit i na straně infrastruktury, jako první krok DNF alespoň zapne automatickou synchronizaci metadat přes cron. Druhý problém je rychlost vyhledávacích operací: ty jsou v libsolvu obvykle rychlejší než v Yumu, zejména operace související s depsolvingem jsou dobře optimalizovány, bohužel ale nezanedbatelný čas trvá úvodní načtení metadat do paměti, proto to ve výsledku vypadá jak píše Jirka a optimalizace zde teprve přijde.
Také bych zdůraznil že rychlost Yumu nebyl primární důvod pro tento fork.
16. 1. 2013 at 12:55
Doufám, že myslíte i na ty, kteří platí za stažená data, a nechce se jim po každém spuštění DNF editovat crontab.
Hodně štěstí při náhradě yumu, už bylo na čase!
17. 1. 2013 at 16:01
Díky.
Myslíme, bohužel ve Fedoře 18 si budou muset synchronizaci sami vypnout. Bug který to řeší je https://bugzilla.redhat.com/show_bug.cgi?id=892064
Nejdřív je ale potřeba aby NetworkManager umožnil rozlišit zda-li se zrovna za stažená data platí nebo nikoliv: https://bugzilla.redhat.com/show_bug.cgi?id=896572