Red Hat Bugzilla – Bug 1212341
[RFE] Allow plugins to override the core configuration
Last modified: 2016-10-04 15:14:12 EDT
I got this silly idea to manage systemd (systemd-nspawn) containers with dnf extended by a plugin. The first intended use case was to have dnf to create the container tree for me.
The intended workflow should have looked like this (assume I wanted a container with httpd):
> dnf mynewplugin --machine "my-container" install httpd
mynewplugin was supposed to:
* detect where I have the containers stored (e.g., /var/lib/machines)
* create '/var/lib/machines/my-container' directory if it does not exist yet
* install httpd package and its dependencies using '/var/lib/machines/my-container' as the installroot
It turned out that overriding the installroot from a plugin is not that easy: If I understood the code correctly then dnf first initializes itself using the configuration + command line arguments. This includes loading the installed package list. And only after that the plugin gets initialized too. However in my case the goal was to guess one of the configuration options (installroot) in the plugin. Even more oddly, when the configuration is changed from the plugin, dnf happily starts installing into the plugin specified installroot using the dependencies from the default installroot (which fails due to broken dependencies or with "package already installed").
Surely I can work this around by not solving my problem with a dnf plugin. However this design severely limits the dnf possibilities IMO. Would it be possible to consider redesigning the dnf plugin interface somehow?
can you not use the config hook, to set an new install root
Yes, this is an issue with current plugin implementation. Both plugin's configure() and even __init__() run after dnf has parsed its configuration, commandline and repo files. So currently there's no way to change e.g location of rpmdb or repo files.
At least plugin.__init__() should be called before repo parsing, opening rpmdb etc.
But let's add another hook instead of forcing plugins to do this in the __init__ method.
This would also allow fedup-style upgrades to be implemented as a DNF plugin.
Ideally, system upgrades would look something like:
dnf distro-upgrade download VERSION [--datadir=DATADIR] [--distro-sync]
Which is basically the same as:
dnf update --releasever=NEW_VERSION --download-only --destdir=DESTDIR
(except --download-only and --destdir don't exist.. but you understand what I mean.)
This would be a pretty easy plugin to write, but right now there's no way for plugins to override/reset $releasever.
(It's also a pain to do this as a DNF extension, because if you pass a Conf to dnf.Base to change releasever, it doesn't add CACHEDIR_SUFFIX to conf.cachedir..)
Will, `conf.substitutions['releasever'] = XX` doesn't wok for you? DNF from 1.1.0 don't have cachedir bound to releasever.
(In reply to Jan Silhan from comment #5)
> Will, `conf.substitutions['releasever'] = XX` doesn't wok for you? DNF from
> 1.1.0 don't have cachedir bound to releasever.
The problem is making sure the URLs get set correctly. If the user does:
dnf system-upgrade 23
Then by the time the system-upgrade plugin starts, the repo configs have already been parsed, with releasever set to "22" (or whatever version the host system is).
So, as far as I know, that won't help, unless:
a) there's new behavior that re-parses all the repo URLs when conf.substitutions['releasever'] is modified, or
b) there's a new plugin hook that allows plugins to change $releasever before the repo configs are parsed.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.