On Fri, Mar 13, 2020 at 12:23 PM Pat Riehecky <jcpunk@xxxxxxxxx> wrote: > > On Fri, Mar 13, 2020 at 9:48 AM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > > > Daniel Mach <dmach@xxxxxxxxxx> writes: > > > > > Dne 12. 03. 20 v 19:26 Pat Riehecky napsal(a): > > > > > >> I realize I'm thinking about the Pie in the Sky, but: > > >> > > >> Would it be possible for 'microdnf' to become the base for 'dnf' so > > >> that extra 'dnf' functionality is added via some kind of > > >> modules/plugins/etc behaviour? Perhaps "somehow" it could (for > > >> example) find out "oh I've got python, lets load those feature bits > > >> too". > > >> > > >> This could help keep them fully compatible and let folks using dnf > > >> based installers look at pulling in just the features they require. > > > > > > I don't think we're ready for this yet. We need to work on improving > > > libdnf and delivering a dbus interface in the first place as > > > announced. Once we're finished with these changes, we'll definitely > > > look into making python optional. > > > > This confuses me. microdnf works today. This means that python is > > *already* optional. > > > > I believe what's being suggested is to stop duplicating microdnf > > functionality in python. That way reduces code duplication, which means > > there's less to maintain, test functionality between, etc.. > > > > Pat has suggested a particular way this might be accomplished (module > > detection with a module providing python capability), but the details of > > this strike me as less important than having fewer package managers. > > > > Thanks, > > --Robbie > > That is what I attempted to suggest (though worded better). > The problem is that MicroDNF barely works like DNF does today in terms of basic operations, and is architecturally not structured to support becoming the main "core" of the DNF package manager frontend. Moreover, it does not present output in the same way that the main DNF frontend does, nor does it handle options the same way. A lot of how MicroDNF works will need to change to become the core of a new DNF frontend, essentially mandating a rewrite of the application. A rewrite is already planned, but making a rewritten version of MicroDNF available is not planned anytime soon. The existing MicroDNF works with libdnf from the DNF 4 stack, and that will stay basically the same while the DNF 5 stack is being developed. With everything else going on as part of the DNF 5 development, I do not think this will be possible to change this unless there's more developers to help with making that transition possible. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
