Implement drop-in configuration folder (RhBug:1352234)

[jamescassell]

This is a rebase of #887

depends on rpm-software-management/libdnf#751

[Conan-Kudo]

@jamescassell Can you fix your authorship of your commit?

[Conan-Kudo]

We also need similar handling for this in libdnf itself, so that PackageKit and other things using libdnf directly can leverage it...

[jamescassell]

@jamescassell Can you fix your authorship of your commit?

Not sure how. I didn't make the change, only resolved the conflicts from the original PR...

not sure where to make the change in libdnf but I'll take a look

[jamescassell]

commit authorship fixed

[Conan-Kudo]

@j-mracek Could you check this too?

[Conan-Kudo]

@jamescassell Can you rebase the AUTHORS file modification? Then we can look to get this in.

[jrohel]

@jamescassell Hi. Thank you for the PR. It's a good idea to support drop-in configuration folder.
I would like to merge the code. But there are still some problems.

1. We need to add the same support into libdnf (microdnf, PackageKit, ... must use the same configuration files)
2. There is config-manager plugin: https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/config_manager.py . With this patch the plugin will use configuration from drop-in folder but the result will be saved into main config file. And the main config file has lower priority than drop-in folder. The plugin will be unusable in these situations.

[jamescassell]

I'll try to take a look when I get a moment.

[j-mracek]

I would like to propose other mechanism that will allow to change default configuration for a particular downstream without modification of /etc/dnf/dnf.conf.

I suggest that we need a configuration file that will be not handled by rpm as configuration, therefore the content will be overwritten during updates. At the top there will be note that this file is not supposed to be modified by end user, and it is used exclusively for distribution purpose. The question would be where the file will be located, because there must be a reference in man pages.

Why I don't like a drop in folder for configuration for DNF. In case that multiple files will be presented there the final behaviour will depend on the name of files. For append option the behaviour is fine put for other type configuration it will lead in non transparent situation. Think about 5 configuration files (from distribution, dnf-plugins, application that uses API, GUI, ...) then the situation will be very messy. And nothing will be wrong because it is allowed.

@Conan-Kudo Please if there is any other requirement for drop in configuration directory, please provide additional user-cases or stories.

[Conan-Kudo]

@j-mracek From my side, I have two major requirements:

1. Vendor shipped configuration for DNF that can be modified/overridden by users/admins
2. Vendor shipped repos and vars that can be modified/overridden by users/admins

What I would envision is supporting having configuration files in /usr/share/dnf/config (or /usr/etc/dnf in the openSUSE case) that ship the vendor provided configuration for things (dnf.conf, protected.d, aliases.d, etc.). This would essentially be systemd-style configuration.

For repositories, /usr/share/yum.repos.d (or /usr/etc/yum.repos.d in openSUSE's case) would be shipped there, and we'd have systemd-style overriding behaviors in /etc/yum.repos.d.

I think that libeconf is probably the way to go to help make that straightforward, but I'm open to suggestions.

[j-mracek]

@j-mracek From my side, I have two major requirements:

1. Vendor shipped configuration for DNF that can be modified/overridden by users/admins

2. Vendor shipped repos and vars that can be modified/overridden by users/admins

What I would envision is supporting having configuration files in /usr/share/dnf/config (or /usr/etc/dnf in the openSUSE case) that ship the vendor provided configuration for things (dnf.conf, protected.d, aliases.d, etc.). This would essentially be systemd-style configuration.

For repositories, /usr/share/yum.repos.d (or /usr/etc/yum.repos.d in openSUSE's case) would be shipped there, and we'd have systemd-style overriding behaviors in /etc/yum.repos.d.

Please could you be more specific about systemd-style overriding behaviors and what is a difference to systemd-style configuration?

I think that libeconf is probably the way to go to help make that straightforward, but I'm open to suggestions.

But it means to wait, am I correct?

Thanks Neal for explanation. I see as major problem with configuration a difficulty of any changes of defaults during life cycle of the system. But the issue is already handled by DNF plugin rpm-conf (extras). Also I am not sure if any user cases that were already mentioned can be resolved by drop in directory for configuration.

Multi layer repo configuration would require additional changes that will allow multi definition of the same repository. But it also mean that by that way two different repositories could be merged into single object.

[Conan-Kudo]

The rpmconf plugin does not solve the problem of being able to ship configuration for DNF in a stateless manner. And because nobody ships the rpmconf plugin by default, these configuration updates do not get applied regularly anyway.

Regardless, the major goal here is to stop shipping configuration files in /etc and make it so that files in /etc only exist when the user wants to override vendor provided configuration.

[j-mracek]

The rpmconf plugin does not solve the problem of being able to ship configuration for DNF in a stateless manner. And because nobody ships the rpmconf plugin by default, these configuration updates do not get applied regularly anyway.

Regardless, the major goal here is to stop shipping configuration files in /etc and make it so that files in /etc only exist when the user wants to override vendor provided configuration.

Agree, but drop in folder in /etc is not a solution.