Config option priority

[j-mracek]

The discussion should verify the best setting for configuration priority. The following part should provide background with a suggestion haw we can modify them. Please don't hesitate to provide additional use cases or alternatives.

The priority are define here:

dnf5/include/libdnf/conf/option.hpp

Lines 66 to 78 in 370f99f

	enum class Priority {
	EMPTY = 0,
	DEFAULT = 10,
	MAINCONFIG = 20,
	AUTOMATICCONFIG = 30,
	REPOCONFIG = 40,
	INSTALLROOT = 45,
	PLUGINDEFAULT = 50,
	PLUGINCONFIG = 60,
	DROPINCONFIG = 65,
	COMMANDLINE = 70,
	RUNTIME = 80
	};

.

The first disadvantage of our options is that they do not have documentation or description how they are supposed to be used.
I also believe that the current values does not cover all use cases.

In DNF4 we use to often RUNTIME priority for everything in code because priority was introduce later during development.

• I have a difficulty to set proper value for configuration modification by command. Some command requires to modify configuration for proper functionality. As a example I can use download command and destdir configuration. The command downloads packages to current directory therefore it should set "." to destdir. But the value is supposed to be overwritten by --setopt and --destdir. I think that "." should override configuration from files (MAINCONFIG, INSTALLROOT, INSTALLROOT, DROPINCONFIG) because then the command will not work according to documentation.

• Where to have DROPINCONFIG

  • Shell it override INSTALLROOT
    • extension of config paths by installroot is driven by user decision (no autodetection like in dnf4) therefore it might be better to lover priority of DROPINCONFIG

• New priority for Distribution config - it should be used to override

• I am not sure whether we need EMPTY

    EMPTY = 0,
    DEFAULT = 10,
    DISTRODEFAULT = 15,
    MAINCONFIG = 20,
    AUTOMATICCONFIG = 30,
    REPOCONFIG = 40,
    DROPINCONFIG = 45,
    INSTALLROOT = 50,
    PLUGINDEFAULT = 55,
    PLUGINCONFIG = 60,
    COMMANDDEFAULT = 65,  #  will be use for command overrides
    COMMANDLINE = 70,
    RUNTIME = 80
  

[jan-kolarik]

We definitely want to document the meaning of individual priority levels, because then it will be much easier to grasp the relationship between each other not only for clients, but even for us.

One rather minor thing is why we are explicitly defining the numerical values for the priorities? Do we need to keep fixed values for individual priorities for some reason? Otherwise I don't see any advantage of doing this, just disadvantages like worse readability, maintainability, ...

[m-blaha]

I don't think the actual numerical value is ever used or stored anywhere. The only thing that matters is the order of them, so you are right about dropping the numbers, I guess.

[kontura]

I think the set numerical values are good for backwards compatibility. If we add a new priority in the middle of the enum none of the subsequent values will change and therefore clients do not need to recompile.

[m-blaha]

@kontura good point!

[m-blaha]

The EMPTY priority is used to detect that the option value is not set. This is important for options which are both main and repo - if the repo option is not set, the value is taken from the parent (main) option.

[j-mracek]

The most important part related to priority mechanism - where user and config-manager is supposed to add overrides for main configuration and for repositories?