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

Posted Mar 29, 2018 2:20 UTC (Thu) by jhoblitt (subscriber, #77733)
Parent article: DNF 3: better performance and a move to C++

Does this mean that the `dnf` command itself is going to be python free? That would be a step towards smaller minimum docker images that need a python interpreter. It would also mean that a broken system python doesn't brick the package manger (this has happened to me...).

to post comments

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

Posted Mar 29, 2018 3:22 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (15 responses)

Have you looked into microdnf for the container use case? Might not need this in the future.

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

Posted Mar 29, 2018 15:15 UTC (Thu) by jhoblitt (subscriber, #77733) [Link] (3 responses)

https://github.com/rpm-software-management/microdnf ? I was completely unaware of it. Are there any public docker images using it? A quick search turned up `registry.access.redhat.com/rhel7-atomic` but I don't have a rhel subscription.

My team has been moving towards using `alpine` for minimal containers but being musl based, it often doesn't play nice with 3rd party binaries. There is a `glibc` `alpine` variant I've been experimenting with.

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

Posted Mar 29, 2018 15:19 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

In addition to RHEL, CentOS & Fedora images etc should be.

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

Posted Mar 29, 2018 16:26 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

fedora-minimal is.

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

Posted Mar 29, 2018 17:05 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

It took me awhile to find a `fedora-minimal` but it is certainly a lot smaller that the official docker hub images:

registry.fedoraproject.org/fedora-minimal:latest -- 115MB
docker.io/fedora:27 -- 235MB

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

Posted Apr 3, 2018 7:58 UTC (Tue) by dmach (guest, #123441) [Link] (10 responses)

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.

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