DNF 5 -paketinhallinnan ja PackageKit-korvauksen kehitys on alkanut

Daniel Mach Red Hatista сообщил noin DNF 5 -paketinhallinnan kehityksen alusta, jossa Pythonissa toteutettu DNF-logiikka siirretään C++:lla kirjoitettuun libdnf-kirjastoon. DNF 5:n on suunniteltu alkavan testata kesäkuussa Fedora 33:n kehitystyön aikana, minkä jälkeen se lisätään Rawhide-arkistoon lokakuussa 2020 ja korvaa DNF 2021:n helmikuussa 4. DNF 4 -haaran ylläpito jatkuu entisellään. käytetään Red Hat Enterprise Linux 8:ssa.

On huomattava, että projekti on saavuttanut tilan, jossa on lähes mahdotonta jatkaa koodin kehittämistä rikkomatta yhteensopivuutta API/ABI-tasolla. Tämä johtuu pääasiassa tappio PackageKitin merkitys ja mahdottomuus kehittää libdnf:ää muuttamatta "libhif" API:ta. Samaan aikaan, huolimatta aikomuksesta muuttaa API:ta, taaksepäin yhteensopivuuden ylläpitämisen komentoriviliittymän ja API:n tasolla sanotaan olevan pääprioriteetti.

Python API:n tuki DNF:ssä säilytetään, mutta Pythonilla kirjoitettu liiketoimintalogiikka siirretään libdnf (C++) -kirjastoon, mikä varmistaa paketinhallinnan identtisen toiminnan jakelussa. Kehitys keskittyy C++ API:n ympärille ja Python API luodaan automaattisesti sen pohjalta kääreen muodossa.
Sidot Go, Perl ja
Rubiini. Kun C++ API on stabiloitunut, sen pohjalta valmistetaan C API, johon rpm-ostree siirretään. Hawkey Python API poistetaan ja korvataan libdnf Python API.

DNF:n ydintoiminnot säilytetään. Suuren testipaketin (noin 1400 XNUMX testiä) vuoksi on odotettavissa, että API-uudistus ei vaikuta loppukäyttäjien komentorivikäyttöliittymään. Argumenttien jäsennys ja tulos voivat muuttua hieman, mutta nämä muutokset dokumentoidaan hyvin. Riisutussa versiossa microdnf, jota käytetään säiliöissä, on tarkoitus ottaa käyttöön osa DNF-ominaisuuksia; toiminnallisuuden täyden pariteetin saavuttamista ei harkita.

Sen sijasta PackageKit Luodaan uusi DBus-palvelu, joka tarjoaa käyttöliittymän graafisten sovellusten pakettien ja päivitysten hallintaan. Tämä palvelu on suunniteltu kehitettävän tyhjästä, joten sen luominen voi viedä paljon aikaa. PackageKitiä ei ole kehitetty viime aikoina, ja se on ollut ylläpitotilassa vuodesta 2014 lähtien merkityksen menettämisen vuoksi. Snaps- ja Flatpak-järjestelmien kehittymisen myötä jakelut menettävät kiinnostuksensa PackageKitiin, esimerkiksi se ei ole enää saatavilla koontiversioina. Fedora hopeansininen. Pakettien hallinnan abstraktiokerroksen tarjoavat suurelta osin alkuperäiset GNOME- ja KDE-sovellusten ohjauskeskukset, jotka mahdollistavat flatpak-pakettien asennuksen yksittäisten käyttäjien tasolla. Yhtenäinen järjestelmäsovellusliittymä asennettujen pakettien luettelon saamiseen ei ole yhtä hyödyllinen kuin ennen.

Lähde: opennet.ru

Lisää kommentti