Hello, I do not see how the actual issue could be solved by storing config files at a different location. I think the actual issue is the conflict between what the admin wants to have in his config files versus what a Linux distributor wants to have in his config files. I think the actual issue is the conflict who has the final say in what the config files content is. Because I think there is no automated way to solve that conflict I think the functionality that RPM provides is basically all what can be done in practice. Files not marked: The Linux distributor has the final say in the files content (and admin changes get overwritten/lost). Files marked as %config: The Linux distributor has the final say in the files content (and admin changes are saved as file.rpmsave). Files marked as %config(noreplace): The admin has the final say in the files content (and Linux distributor content is provided as file.rpmnew). When files got changed the admin must manually solve things as he needs it in his particular case. I think the crucial point is that the admin can reliably determine all that has changed. On Jun 3 13:50 Thorsten Kukuk wrote (excerpt):
If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
Offhandedly this looks like a packaging issue because when only a cosmetic typo in a comment was fixed the new config file should be marked as '%config(noreplace)' - but I don't know what happens if the old RPM has '%config' and the new one has '%config(noreplace)' and vice versa.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
But https://users.suse.com/~kukuk/SUSE-CaaSP-Docu/transactional-update.8.html reads: "Changes made to the running root filesystem after transactional-update was started are lost after the next reboot" so it is documented what happens when "admin makes changes to the configuration file" after he "starts an transactional update". I do not understand the "overlay filesystem" part in https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#rpm-... that reads "RPM does not see, that there are modified versions of the config file (e.g. they are stored in an overlay filesystem)" I guess what is meant is that in the running system there is an overlay filesystem e.g. for /etc/ but that does not get included in the snapshot (i.e. the snapshot contains old/outdated files underneath the overlay filesystem). Offhandedly this looks like an issue with creating the snapshot of the running system which is in this special case not a valid snapshot of the running system. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - HRB 21284 (AG Nuernberg) GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org