Which components/packages are best candidates for adding a feature which would make it easier for users to track changes from the default %config %files on the system?
I've found this to be a deficiency, requiring users to do configuration management independently of the installer tools on a system, and I think the situation could be improved by adding functionality to the installation tooling to track these changes better. For example, I can see which %config files have changed with `rpm -V`, but I can't see what the changes actually are unless I do `dnf download $myrpm`, extract it, and diff them. Alternatively, I could rename the configuration file, and do a `dnf reinstall $myrpm` to replace the original, and then diff them. Both of these methods are clunky, wasteful, and not without side-effects. rpmconf is nice, because it helps me easily compare configuration files whose user-changes and maintainer-changes conflict... but that's not quite the same thing. Here's some things I was thinking: rpm could track more than hashes of config files, and instead track the full file. This could be optional, as it uses more disk space, but disk space is cheap these days, and config files are relatively small. This would avoid having to re-download the rpm, and would make it easier to see what has been modified on their system. So, some users may find that a worthwhile trade-off. Alternatively, dnf could also add an '--update-configs' option to the 'reinstall' command, to force the creation of rpmorig/rpmnew files for reinstall (currently these only get created during updates, as far as I understand it). This won't avoid the re-download, but might be an easier solution, and wouldn't require the extra disk space (after the rpm is reinstalled). This option would enable the existing rpmconf to do its job. rpmconf might also need modification to support tracking configuration management more fully, rather than just for updates. I'm sure there's other components/solutions (in general, I find `git init /etc/` to be quite convenient, but it's a messy hack). Any thoughts? Is this an area which can be improved easily? Are there existing solutions within Fedora? Something we could bring in? Specific upstream packages we can target for feature requests?
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
