Bug 1193823

Summary:	[RFE] Plugins can't be disabled in config files
Product:	[Fedora] Fedora	Reporter:	Michael Mráka <mmraka>
Component:	dnf	Assignee:	Michael Mráka <mmraka>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	akozumpl, jsilhan, jzeleny, mluscon, mmraka, packaging-team-maint, pnemade, tim.lauridsen
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-22 08:44:22 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:

Description Michael Mráka 2015-02-18 10:34:46 UTC

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 11:43:01 UTC

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 12:22:52 UTC

> 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 12:45:08 UTC

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 13:04:44 UTC

(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 12:15:02 UTC

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 14:20:12 UTC

wait libhif? howcome this is related to libhif and targeted for F25 that is too long.

Comment 7 Radek Holy 2015-07-20 15:28:17 UTC

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 15:38:36 UTC

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 15:48:25 UTC

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 10 Michael Mráka 2016-05-11 08:34:34 UTC

https://github.com/rpm-software-management/dnf/pull/492

Comment 11 Igor Gnatenko 2016-07-22 08:44:22 UTC

Fixed as part of DNF 2.0 release which will be available at some point soon.