Наскоро Разработчиците на Fedora обявиха намеренията си да мигрират дистрибуцията към новия мениджър на пакети извика Вместо това „Microdnf“. от мениджъра на пакети "DNF" който се използва в момента.
Първата стъпка по пътя към миграцията ще бъде голяма актуализация на Microdnf, планирано за Fedora 38, който ще се доближи по функционалност до DNF и дори ще го надмине в някои области.
Споменава се, че намеренията за извършване на тази миграция се дължи на ключовата разлика между Microdnf и DNF е използването на C вместо Python за развитие, което ви позволява да се отървете от много зависимости.
В един момент DNF замени Yum, който беше написан изцяло на Python, а в DNF, изискващите производителност функции на ниско ниво бяха пренаписани и преместени в отделни библиотеки hawkey, librepo, libsolv и libcomps C, но рамката и високо- компонентите на ниво останаха в езика Python.
Първоначално Microdnf е разработен като опростена версия на DNF за използване в Docker контейнери, които не изискват инсталиране на Python. Сега разработчиците на Fedora планират да доведат Microdnf до нивото на DNF функционалност и в крайна сметка напълно да заменят DNF с Microdnf.
Голяма актуализация на Microdnf е първата стъпка в еволюцията на управлението на пакети във Fedora. Новият microdnf има амбицията да предостави всички основни характеристики на DNF, без да губи минималния си отпечатък.
Microdnf се базира на библиотеката libdnf5, разработен като част от проекта DNF 5. DNF 5 има за цел да обедини съществуващите библиотеки от ниско ниво, да пренапише останалите операции за управление на пакети Python в C++ и да премести основната функционалност в отделна библиотека със създаването на обвързване около тази библиотека, за да запази API на Python.
MICRODNF значително подобрява потребителското изживяване и ще предостави всички важни характеристики на DNF в бъдеще. Той също така ще запази всички предимства на оригиналния MICRODNF, като минималния размер, необходим за контейнерите.
Новата версия на Microdnf също ще използва фоновия процес DNF Daemon, замяна на функционалността PackageKit и предоставяне на интерфейс за управление на пакети и актуализации в графични среди. За разлика от PackageKit, DNF Daemon ще поддържа само RPM формат.
Microdnf, libdnf5 и DNF Daemon са планирани да се доставят заедно с традиционния DNF инструментариум в първата фаза на внедряване. След като проектът приключи, новият пакет ще замени пакети като dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora и python3-dnfdaemon.
От области, където Microdnf превъзхожда DNF, той се откроява: по-визуална индикация за хода на операциите; подобрено изпълнение на таблицата на транзакциите; възможността за показване на информация в отчети за завършени транзакции, която се издава от пакетирани скриптлети (скриптлети); поддръжка за използване на локални RPM пакети за транзакции; по-усъвършенствана система за завършване на въвеждане за bash; поддръжка за изпълнение на командата builddep без инсталиране на Python в системата.
Сред недостатъците промяна на мениджъра на пакети на дистрибуцията на Microdnf е промяната в структурата на вътрешните бази данни и обработката на отделната база данни от DNF, което няма да ви позволи да видите транзакции с пакети, направени в DNF в Microdnf и обратно.
Пакетите, инсталирани преди това с DNF, ще бъдат третирани като "потребител, инсталиран от dnf history" след мигриране към Microdnf и деинсталирането на пакет, инсталиран от друг мениджър на пакети, няма да премахне неизползваните зависимости, свързани с него. Също така, Microdnf не планира да поддържа 100% поддръжка на DNF на командно ниво и опциите на командния ред.
Отбелязва се, че новата версия на Microdnf ще поддържа всички основни характеристики на DNF, но в същото време ще запази висока производителност и компактност.
И накрая, ако имате интерес да научите повече за него, можете да се консултирате подробностите в следващия линк.
Нов съм в програмирането и съм ентусиазиран от Linux. Никога не съм използвал Fedora, защото винаги имам проблем с инсталацията и се оказвам с Debian (и производни) или OpenSUSE. Но мисля, че разбирам важността в света на Linux и колко уместно се случва това във Fedora.
Съмненията ми идват от идеята за заместване на Python с C/C++, защо да се прилага с език на ниско ниво, който е силно критикуван заради неговите варианти и лошо дефинирания си стандарт? Разбирам малко промяната от интерпретиран език към компилиран, но не разбирам прескачането към език, за който видях, че се търси да се използва по-малко в някои области. Не би ли било по-добре да използвате Rust или C#?
Не критикувам решенията на хората на Fedora, но се стремя да разбера как напредва светът на програмирането. Уча Python и JS в мрежата и реших да се върна към C/C++ за основите, така че тази бележка изглежда, че може да ми помогне с фокуса.
Много благодаря! И отлична работа както винаги за хората от <•DesdeLinux