Bug 1980712
| Summary: | dnf --enableplugin and --disableplugin issues | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Peter Ajamian <peter> | |
| Component: | dnf | Assignee: | Jan Kolarik <jkolarik> | |
| Status: | CLOSED ERRATA | QA Contact: | Eva Mrakova <emrakova> | |
| Severity: | low | Docs Contact: | ||
| Priority: | low | |||
| Version: | 8.4 | CC: | james.antill, jkolarik, jrohel, mbanas, tbajer | |
| Target Milestone: | beta | Keywords: | Triaged | |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | dnf-4.7.0-13.el8 | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2121664 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-16 09:06:59 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: | 2121664 | |||
|
Description
Peter Ajamian
2021-07-09 11:01:44 UTC
The problem is inconsistency between the plugin name and name of the command implemented by the plugin. Commands usually use "-" in the name, but always "_" in the plugin name. Eg. the "config-manager" command is implemented in the "config_manager" plugin. So, to its disabling `--disableplugin=config_manager` is required. This is really confusing, especially when you look at the list of "Loaded plugins" in the dnf -v ... output. "config-manager" is shown with a dash, but the actual plugin name has an underscore. "debuginfo-install" is shown with a dash and the actual plugin name actually has a dash. "generate_completion_cache" is shown with underscores, and the actual plugin name is with underscores. The fact that --enableplugin=config-manager actually works to enable the plugin, despite outputting an error adds further to the confusion. Given the above, and that all the documentation seems to refer to the "command name" and not the actual plugin name that is needed for disablerepo or enablerepo, how is one supposed to know, barring trial and error, what the actual plugin name is? Also the docs could be way clearer in this respect. I would venture to say that things would be way clearer, and way easier, if the plugin name and command name always matched, as a guideline. ...also: what exactly *is* displayed in the dnf -v ... output? It's obviously not the plugin name, so is it the command name, or some sort of display name or ??? Can the --enableplugin and --disableplugin options be fixed to accept these names as aliases to the plugin name? We consider the bug as a valid but because the issue has limited impact (low priority) we postpone the issue in favor of other issues. Thanks for the update, I do appreciate that it's low priority. Would it be appropriate to push the bug to the upstream project and just let the fix filter down to Fedora and eventually RHEL when it rebases? New implementation will support passing the actual plugin name to the --disableplugin and --enableplugin parameters and also the current way using the underscores is supported. Following PRs were queued to fix this: fix: https://github.com/rpm-software-management/dnf/pull/1839 tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/1141 Thanks Jan I think that will work great! I'll try applying that patch against my version of dnf and make sure it fixes the issue, I'll get back to you with the results. One comment on the tests, I think that the test to enable the plugin should make sure that the plugin is disabled first, otherwise the test doesn't really know if it's really been enabled or not. You're right Peter about the tests. I was focused on the unknown plugin message which works also in this case, but the tests should also check the actual enabling as well. I'll fix that. I can confirm that in both EL8 and EL9 (Tested against Rocky Linux this time) if I apply the patch directly to plugin.py from the python3-dnf package that it fixes the issue: https://github.com/rpm-software-management/dnf/commit/a7b22adceb2780e8668b0e9b193ff641df660c77.diff Will we see this applied to the RHEL 8 and RHEL 9 dnf? I'm okay living with this minor bug but it would be nice to have it fixed in the current releases of RHEL. Peter (In reply to Peter Ajamian from comment #10) > I can confirm that in both EL8 and EL9 (Tested against Rocky Linux this > time) if I apply the patch directly to plugin.py from the python3-dnf > package that it fixes the issue: > > https://github.com/rpm-software-management/dnf/commit/ > a7b22adceb2780e8668b0e9b193ff641df660c77.diff > > Will we see this applied to the RHEL 8 and RHEL 9 dnf? I'm okay living with > this minor bug but it would be nice to have it fixed in the current releases > of RHEL. > > > Peter Yes, we are planning to deliver the fix into RHEL 8.8 and 9.2. Sorry for the late response, I needed to confirm this information. Cloned into RHEL 9 ticket https://bugzilla.redhat.com/show_bug.cgi?id=2121664. (In reply to Jan Kolarik from comment #11) > Yes, we are planning to deliver the fix into RHEL 8.8 and 9.2. Sorry for the > late response, I needed to confirm this information. That's great, thanks! Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (dnf bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2980 |