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:
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?
> 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.
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.
(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.
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
wait libhif? howcome this is related to libhif and targeted for F25 that is too long.
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?
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 :)
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.
https://github.com/rpm-software-management/dnf/pull/492
Fixed as part of DNF 2.0 release which will be available at some point soon.