DNF 3: better performance and a move to C++

Posted Apr 3, 2018 7:58 UTC (Tue) by dmach (guest, #123441)
In reply to: DNF 3: better performance and a move to C++ by rahulsundaram
Parent article: DNF 3: better performance and a move to C++

Microdnf is definitely an option if you're looking for minimal system footprint.
Unfortunately it sometimes behaves differently than DNF.
That's why we're currently consolidating the whole software management stack.

Sooner or later, microdnf will gain most of the DNF features through libdnf.
What's not clear yet is how to deal with plugins, which are written in Python.

to post comments

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 17:47 UTC (Wed) by hkario (subscriber, #94864) [Link] (1 responses)

wouldn't graceful failure handling be possible in case module load fails?

also, I don't think removing support for python plugins is a good idea: ease of writing them lowers the barrier to entry and tools like Gimp are only better for support of them

DNF 3: better performance and a move to C++

Posted Apr 6, 2018 6:16 UTC (Fri) by dmach (guest, #123441) [Link]

I'm not sure about the graceful failure handling.
Sometimes it's better to report an error than ignore it and exit with 0.
That could make a false assumption that everything works perfectly.

About the plugins support - we do *not* have any plans to remove them from Python DNF.
On the other hand, it would be great to support plugins directly in libdnf,
in order to make them available to all tools based on the library.
We can't link libdnf with Python to keep the footprint and deps small.
Once the software management stack consolidation is finished,
we'll definitely look into this. Now it's early to say how the solution will look like.

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 18:04 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Why should a tool like DNF even have plugin support?

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 18:16 UTC (Wed) by jhoblitt (subscriber, #77733) [Link] (6 responses)

Why shouldn't it? YUM/DNF plugins are widely used.

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 20:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Debian does it just fine without plugins. Simply provide helper executables that change configuration files as required (see: fastermirror). There's really no reason for a package manager to have in-process plugins.

And some plugins (like langpack) should just be provided as core functionality.

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 20:31 UTC (Wed) by jhoblitt (subscriber, #77733) [Link] (4 responses)

You can make the same modularity argument about just about any software. Why does a kernel need loadable modules? Why does `dlopen` need to exist? Why does an operating system need a package manager? Because example X does without it.

I gather that your satisfied with wrapper scripts like `apt-fast` and similar but it is arguably a poor experience for inexperienced end users. It also places more demands on project maintainers.

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 21:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> You can make the same modularity argument about just about any software.
Absolutely.

> Why does a kernel need loadable modules?
By the same token, the kernel doesn't have pluggable CPU schedulers (and there was a huge flame war about that, just ask Con Kolivas).

> I gather that your satisfied with wrapper scripts like `apt-fast` and similar but it is arguably a poor experience for inexperienced end users. It also places more demands on project maintainers.
Why should there be "apt-fast"?!? The default apt should already be fast without any plugins.

Package retrieval is basically a solved problem, the set of plugins is stable for ages. Integrate them all into the core and forget about it.

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 22:46 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> Package retrieval is basically a solved problem, the set of plugins is stable for ages. Integrate them all into the core and forget about it.

Not quite. There are some which are stable but there is plenty of experimentation in this area of packaging. A recent example is the modularity project implemented via a plugin. There are also things that apply in specific circumstances (snapper) or only one distro among the many which use dnf now (subscription-manager plugin). Several of the plugins have been integrated into core when it made sense (delta rpms in yum used to be handled via a plugin originally) but not all of them fit that way.

DNF 3: better performance and a move to C++

Posted Apr 4, 2018 23:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

That's fine. Just fork a package and experiment with it. Internal modularity in the source code is, of course, important.

DNF 3: better performance and a move to C++

Posted Apr 5, 2018 0:17 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> That's fine. Just fork a package and experiment with it. Internal modularity in the source code is, of course, important.

That is painful compared to plugins and it only covers one of the use cases I was talking about