Ostatnio Deweloperzy Fedory ujawnili swoje zamiary migracji dystrybucja do nowego menedżera pakietów o nazwie Zamiast tego „Mikrodnf” z menedżera pakietów „DNF” który jest obecnie używany.
Pierwszym krokiem na drodze do migracji będzie duża aktualizacja Microdnf, planowane dla Fedory 38, który pod względem funkcjonalności zbliży się do DNF, a nawet przewyższy go w niektórych obszarach.
Wspomina się, że intencje przeprowadzenie tej migracji jest spowodowane kluczową różnicą między Microdnf i DNF jest użycie C zamiast Pythona na rozwój, który pozwala pozbyć się wielu zależności.
W pewnym momencie DNF zastąpił Yum, który został napisany w całości w Pythonie, a w DNF, wymagające wydajności funkcje niskiego poziomu zostały przepisane i przeniesione do oddzielnych bibliotek C hawkey, librepo, libsolv i libcomps, ale framework i wysoko komponenty poziomu pozostały w języku Python.
Microdnf został pierwotnie opracowany jako uproszczona wersja DNF do użytku w kontenerach Docker, które nie wymagały zainstalowania Pythona. Teraz programiści Fedory planują przenieść Microdnf do poziomu funkcjonalności DNF i ostatecznie całkowicie zastąpić DNF przez Microdnf.
Główna aktualizacja Microdnf to pierwszy krok w ewolucji zarządzania pakietami w Fedorze. Nowy microdnf ma ambicję, aby zapewnić wszystkie podstawowe funkcje DNF bez utraty jego minimalnej powierzchni.
Microdnf bazuje na bibliotece libdnf5, opracowany w ramach projektu DNF 5. DNF 5 ma na celu ujednolicenie istniejących bibliotek niskiego poziomu, przepisanie pozostałych operacji zarządzania pakietami Pythona w C++ i przeniesienie podstawowych funkcji do oddzielnej biblioteki z utworzeniem powiązania wokół tej biblioteki, aby zachować API Pythona.
MICRODNF znacznie poprawia wrażenia użytkownika i zapewni wszystkie ważne funkcje DNF w przyszłości. Zachowa również wszystkie zalety oryginalnego MICRODNF, takie jak minimalny rozmiar wymagany dla pojemników.
Nowa wersja Microdnf użyje również demona DNF procesu w tle, zastąpienie funkcjonalności PackageKit i udostępnienie interfejsu do zarządzania pakietami i aktualizacjami w środowiskach graficznych. W przeciwieństwie do PackageKit, demon DNF obsługuje tylko format RPM.
Microdnf, libdnf5 i demon DNF mają być dostarczane wraz z tradycyjnym zestawem narzędzi DNF w pierwszej fazie wdrażania. Po zakończeniu projektu nowy pakiet zastąpi pakiety takie jak dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora i python3-dnfdaemon.
Z obszary, w których Microdnf jest lepszy od DNF, wyróżnia się: bardziej wizualne wskazanie postępu operacji; ulepszona implementacja tabeli transakcji; możliwość wyświetlania w raportach informacji o zrealizowanych transakcjach, które są wystawiane przez spakowane scriptlety (scriptlets); obsługa wykorzystania lokalnych pakietów RPM do transakcji; bardziej zaawansowany system uzupełniania danych wejściowych dla bash; obsługa uruchamiania polecenia builddep bez instalowania Pythona w systemie.
Wśród wad zmiana menedżera pakietów dystrybucji na Microdnf jest zmiana struktury wewnętrznych baz danych oraz przetwarzanie oddzielnej bazy danych z DNF, co nie pozwoli Ci zobaczyć transakcji z paczkami wykonanymi w DNF w Microdnf i odwrotnie.
Pakiety zainstalowane wcześniej z DNF będą traktowane jako „użytkownik zainstalowany z historii dnf” po migracji do Microdnf, a odinstalowanie pakietu zainstalowanego przez innego menedżera pakietów nie usunie nieużywanych zależności z nim związanych. Ponadto Microdnf nie planuje utrzymywać 100% obsługi DNF na poziomie poleceń i opcjach wiersza poleceń.
Należy zauważyć, że nowa wersja Microdnf będzie obsługiwać wszystkie główne funkcje DNF, ale jednocześnie zachowa wysoką wydajność i zwartość.
Na koniec, jeśli chcesz dowiedzieć się więcej na ten temat, możesz skonsultować się szczegóły w poniższym linku.
Jestem nowy w programowaniu i jestem entuzjastą Linuksa. Nigdy nie korzystałem z Fedory, ponieważ zawsze mam problem z instalacją i kończę na Debianie (i pochodnych) lub OpenSUSE. Ale myślę, że rozumiem znaczenie w świecie Linuksa i znaczenie tego, co dzieje się w Fedorze.
Moje wątpliwości wynikają z pomysłu zastąpienia Pythona C/C++, po co implementować językiem niskopoziomowym, który był mocno krytykowany za swoje warianty i słabo zdefiniowany standard? Trochę rozumiem zmianę z języka interpretowanego na język skompilowany, ale nie rozumiem przeskoku do języka, w przypadku którego, jak zauważyłem, w niektórych obszarach dąży się do mniejszego użycia. Czy nie byłoby lepiej użyć Rust lub C#?
Nie krytykuję decyzji ludzi Fedory, ale staram się zrozumieć, jak rozwija się świat programowania. Uczę się Pythona i JS w sieci i pomyślałem, że wrócę do C/C++, aby uzyskać podstawy, więc ta notatka może mi pomóc w skupieniu się.
Bardzo dziękuję! I jak zawsze doskonała robota dla mieszkańców <•DesdeLinux