Bug 1193823 - [RFE] Plugins can't be disabled in config files
[RFE] Plugins can't be disabled in config files
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michael Mráka
Fedora Extras Quality Assurance
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-18 05:34 EST by Michael Mráka
Modified: 2016-10-04 15:13 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-22 04:44:22 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 Michael Mráka 2015-02-18 05:34:46 EST
Description of problem:
dnf plugins can be disabled from commandline (--disablepugin) but not from 
config files.

Version-Release number of selected component (if applicable):
dnf-0.6.4-1.fc22.noarch.rpm

How reproducible:
always

Steps to Reproduce:
1. dnf -v repolist | grep ghost
2. dnf -v repolist  --disableplugin=ghost | grep ghost
3. cat >>/etc/dnf/plugins/ghost.conf <<EOF
[main]
enabled=0
EOF
4. dnf -v repolist | grep ghost

Actual results:
# dnf -v repolist | grep ghost
Loaded plugins: ghost, needs-restarting, debuginfo-install, copr, playground, snapper, Query, debug, download, protected_packages, builddep, repomanage, kickstart, generate_completion_cache, reposync, noroot
# dnf -v repolist --disableplugin=ghost| grep ghost
# cat ....
# dnf -v repolist | grep ghost
Loaded plugins: ghost, needs-restarting, debuginfo-install, copr, playground, snapper, Query, debug, download, protected_packages, builddep, repomanage, kickstart, generate_completion_cache, reposync, noroot

Expected results:
# dnf -v repolist | grep ghost
Loaded plugins: ghost, needs-restarting, debuginfo-install, copr, playground, snapper, Query, debug, download, protected_packages, builddep, repomanage, kickstart, generate_completion_cache, reposync, noroot
# dnf -v repolist --disableplugin=ghost| grep ghost
# cat ....
# dnf -v repolist | grep ghost

Additional info:
Comment 1 Radek Holy 2015-02-18 06:43:01 EST
AFAIK, there is no code in DNF that reads plugin configs when plugins are initialized. Each plugin has to read the config on each own. So, while I'm not saying that we are not going to implement this YUM compatibility, would it also be OK for you if there will be something like "disableplugin" option in the main DNF configuration file instead so we can discuss which solution is better?
Comment 2 Michael Mráka 2015-02-18 07:22:52 EST
> AFAIK, there is no code in DNF that reads plugin configs when plugins are
> initialized. Each plugin has to read the config on each own. So, while I'm

That's my impression too. IMHO disabling should be a part of dnf.Plugin (mandatory) so it do not rely on the plugin authors that they do not forget implement it.

> not saying that we are not going to implement this YUM compatibility, would
> it also be OK for you if there will be something like "disableplugin" option
> in the main DNF configuration file instead so we can discuss which solution
> is better?

It's an option but I am not very comfortable with it. The big disadvantage of it is the fact that plugin can't be easily installed as disabled by default, e.g subscription manager and spacewalk plugins do that because they need to be registered first.
With plugin.conf it can be simply done by packaging conf file with enabled=0 into their rpm.
Comment 3 Radek Holy 2015-02-18 07:45:08 EST
Makes sense. BTW, these plugins should probably be prepared to handle the case when the system is not registered but the plugin is enabled anyway because the user can easily enable them without knowing that the system must be registered first. So, for this particular use case this feature would be just a performance improvement. So, I think both variants are still valid. It would be nice if we could find another use cases that would make it worth the additional code complexity. Otherwise I would vote for low priority.
Comment 4 Radek Holy 2015-02-18 08:04:44 EST
(In reply to Radek Holy from comment #3)
> It would be nice if we could find another use cases that would make it worth
> the additional code complexity.

I mean in case we would choose the variant with plugin configs. The other variant is easy to implement.
Comment 5 Parag Nemade 2015-07-20 08:15:02 EDT
I have kept "enabled=0" in langpacks.conf but due to dnf design langpacks runs everytime. I would like to know if there is any plan by which that config item can be used. If there are not plans really then I will remove it from langpacks.conf
Comment 6 Parag Nemade 2015-07-20 10:20:12 EDT
wait libhif? howcome this is related to libhif and targeted for F25 that is too long.
Comment 7 Radek Holy 2015-07-20 11:28:17 EDT
Parag, may I know *why* do you *need* to disable the plugin from the configuration file? I mean, *why* the plugin should not run always and *when* it should run?
Comment 8 Parag Nemade 2015-07-20 11:38:36 EDT
No, I don't have any need just want to know. If the workflow is going to remain like all installed plugins run by default then I am fine. I know users can use --disableplugin. I see local plugin's local.conf also have "enabled=true" and langpacks.conf is also have enabled=1 (copied from yum-langpacks).

I think considering above is correct, I will remove "enabled=1" line from langpacks.conf file.

Some user reported bug against dnf-langpacks and asking why he can't use "enabled=0" though I explained him above workflow. I better remove it :)
Comment 9 Radek Holy 2015-07-20 11:48:25 EDT
Thanks for the answer. We'll I'm asking because I hoped that you have a better use case than Michael. Unfortunately it still seems that there is no good use case for this option. OTOH, it seems that the rest of the team still wants to implement this feature despite of the missing use case [1].

[1] For those who want to argue with me: please read again the comment 3.
Comment 11 Igor Gnatenko 2016-07-22 04:44:22 EDT
Fixed as part of DNF 2.0 release which will be available at some point soon.

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