During the recent update to TOS 3.10.4 I noticed quite a number of such warnings:
WARN:Config file foo.bar modified by the user. Backing up the new one into foo.bar-opkg
It seems a bit tedious having to manually compare each of those files in order to figure out whether perhaps a new a/o changed setting is being introduced by the default config file delivered during each update.
ubuntu (bionic) for instance is offering an automated comparision (and merging option) for config files during the update process. Suppose such is not available on with opkg or pkgupdate?
Merging them should not be required. Needed configuration change is done by postupdate script of that specific package. *-opkg files are there just for reference. It is not expected that user is going to be merging them with its configuration. At least not for core packages. But as you correctly pointed out that is not Turris but rather OpenWRT specific approach.
What concerns me though is that there is nothing in the TO change log that documents changes made to configuration files and thus requires a manual review of each such configuration file in order to figure out whether the added/changed configuration is wanted by the user.
It certainly shall be assumed in good faith that any added/changed configuration introduced by an update is for the benefit of the system performance/security/stability rathrer than the contrary.
Yet some users (at least me) would want to be informed about changes made to configuration files.
I am aware that such changes can be traced in the repo’s gitlab which though is a bit cumbersome. Perhaps TO update change logs could be expanded (link to the respective gitlab commit) to elaborate on changes to config files?
We are mostly not changing configuration options. Doing so would be a bad idea. As I wrote what we change is either automaticaly migrated or is not interesting to user. Those changes are tracked in specific software repositories and all that should be handled without user having to interfere with it. Explicitly listing those changes is close to not doing automatic migration and that goes against automatic updates. But as I wrote we are not generaly changing configuration. Most of the configuration changes are from upstream and that is out of our hands. We don’t have resources to track and note every change in configuration in every software we have in repositories.
There is an opkg option opkg list-changed-conffiles. Using that it should be possible to get user customized files. Then it is possible to check if they have been updated during the update process (see modify date of file) and if that is the case to diff it with the -opkg file.
Seen that option but that is not really helpful in this context since the update process is already printing that warning cited in the initial post about configuration files being touched by an update.