Bug 1212341
| Summary: | [RFE] Allow plugins to override the core configuration | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomas Smetana <tsmetana> |
| Component: | dnf | Assignee: | Jaroslav Mracek <jmracek> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | jmracek, jsilhan, jzeleny, mluscon, mmraka, packaging-team-maint, pnemade, tim.lauridsen, vmukhame, wwoods |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 14:24:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1047712 | ||
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 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. The hook is not implemented yet, therefore I have no idea why the bug was closed. I created a patch that provides new pre_config hook (https://github.com/rpm-software-management/dnf/pull/897). Hope that it helps. 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 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 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 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 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. 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. |
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?