Bug 1212341 - [RFE] Allow plugins to override the core configuration
[RFE] Allow plugins to override the core configuration
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jaroslav Mracek
Fedora Extras Quality Assurance
: FutureFeature, Reopened, Triaged
Depends On:
Blocks: 1047712
  Show dependency treegraph
 
Reported: 2015-04-16 04:38 EDT by Tomas Smetana
Modified: 2017-10-04 18:26 EDT (History)
10 users (show)

See Also:
Fixed In Version: dnf-2.7.2-1.fc27 dnf-2.7.2-1.fc26
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-04 10:24:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
http://dnf.readthedocs.org/en/latest/api_plugins.html#dnf.Plugin.config

or maybe

http://dnf.readthedocs.org/en/latest/api_cli.html#dnf.cli.Command.configure
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.
Comment 8 Jaroslav Mracek 2017-08-11 07:25:45 EDT
The hook is not implemented yet, therefore I have no idea why the bug was closed.
Comment 9 Jaroslav Mracek 2017-08-15 10:12:04 EDT
I created a patch that provides new pre_config hook (https://github.com/rpm-software-management/dnf/pull/897). Hope that it helps.
Comment 10 Fedora Update System 2017-10-02 06:35:55 EDT
dnf-plugins-extras-2.0.3-1.fc27 dnf-plugins-core-2.1.4-1.fc27 dnf-2.7.2-1.fc27 libdnf-0.10.1-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-faf235c683
Comment 11 Fedora Update System 2017-10-02 06:38:36 EDT
dnf-plugins-extras-2.0.3-1.fc26 dnf-plugins-core-2.1.4-1.fc26 dnf-2.7.2-1.fc26 libdnf-0.10.1-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-70a8618065
Comment 12 Fedora Update System 2017-10-02 16:29:13 EDT
dnf-2.7.2-1.fc26, dnf-plugins-core-2.1.4-1.fc26, dnf-plugins-extras-2.0.3-1.fc26, libdnf-0.10.1-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-70a8618065
Comment 13 Fedora Update System 2017-10-02 17:28:25 EDT
dnf-2.7.2-1.fc27, dnf-plugins-core-2.1.4-1.fc27, dnf-plugins-extras-2.0.3-1.fc27, libdnf-0.10.1-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-faf235c683
Comment 14 Fedora Update System 2017-10-04 10:24:10 EDT
dnf-2.7.2-1.fc27, dnf-plugins-core-2.1.4-1.fc27, dnf-plugins-extras-2.0.3-1.fc27, libdnf-0.10.1-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2017-10-04 18:26:09 EDT
dnf-2.7.2-1.fc26, dnf-plugins-core-2.1.4-1.fc26, dnf-plugins-extras-2.0.3-1.fc26, libdnf-0.10.1-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

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