Bug 1212341 - [RFE] Allow plugins to override the core configuration
[RFE] Allow plugins to override the core configuration
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: FutureFeature, Triaged
Depends On:
Blocks: 1047712
  Show dependency treegraph
Reported: 2015-04-16 04:38 EDT by Tomas Smetana
Modified: 2016-10-04 15:14 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-10-04 15:14:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Smetana 2015-04-16 04:38:03 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?
Comment 1 Tim Lauridsen 2015-04-16 11:42:34 EDT
can you not use the config hook, to set an new install root

or maybe

Comment 2 Michael Mráka 2015-04-17 03:55:18 EDT
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.
Comment 3 Radek Holy 2015-04-17 06:14:15 EDT
But let's add another hook instead of forcing plugins to do this in the __init__ method.
Comment 4 Will Woods 2015-05-01 15:44:52 EDT
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..)
Comment 5 Honza Silhan 2015-08-18 07:38:41 EDT
Will, `conf.substitutions['releasever'] = XX` doesn't wok for you? DNF from 1.1.0 don't have cachedir bound to releasever.
Comment 6 Will Woods 2015-08-19 17:20:55 EDT
(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.
Comment 7 Fedora Admin XMLRPC Client 2016-07-08 05:24:26 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Note You need to log in before you can comment on or make changes to this bug.