There is no way to list all config files that contributed to a repository configuration

[m-blaha]

Although the override mechanism is well described in Drop-in repo directories section of dnf.conf(5) man page, it can be difficult for users to identify which config files contributed to the final repository state.

A user could run dnf config-manager disable foo, then examine the /etc/yum.repos.d/foo.repo file, see enabled=1, and be confused about why the repository is disabled. dnf repo info foo would show Status: disabled but the Config file: line would point to the original /etc/yum.repos.d/foo.repo file where enabled=1 remains unchanged.

There is no built-in "show me all config sources for this repo" diagnostic. Users must manually check /etc/dnf/repos.override.d/ (and possibly other locations) to find the override.

One option to resolve this issue would be to track every file that contributed to the repository configuration and display them in the dnf repo info output.

[jirihnidek]

It will be very important for replacing subscription-manager repo-override command. It has high priority for us.

[evan-goode]

IMO ideally we would record each time, or at least the last time, each option was set, and by whom. Something like

Option::set(Priority priority, const std::string & value, const std::string & setter);

where setter could be a plugin name or path to drop-in configuration file. It could even be exposed for the user to aid debugging, like vim's verbose set optionname?.

But we couldn't do that without breaking ABI.

[jrohel]

Regarding the ABI concerns, I have some good news and a potential path forward:

• The Good News: The parent Option class implements the pimpl idiom (p_impl). This means we can safely add the new tracking data fields inside the implementation class without breaking ABI compatibility.

• The Complication (and Solution): Introducing a new virtual Option::set method would indeed break the ABI (by altering the vtable). However, we can bypass this by introducing a non-virtual method instead. This looks like a viable way to extend the API/ABI without breaking vtable layouts.

So, there is a chance we can achieve this without breaking the ABI.