There's a nice spec for this by the UAPI group: https://uapi-group.org/specifications/specs/configuration_files_specification/ https://uapi-group.org/specificat

There's a nice spec for this by the UAPI group: https://uapi-group.org/specifications/specs/configuration_files_specification/ https://uapi-group.org/specifications/specs/configuration_fi... , with the most common implementation called libeconf. The tl;dr is that an application / OS vendor can ship the default configuration in a path like /usr/etc, some dynamic runtime component can then override it in a path like /run, and a sysadmin can override that in a path like /etc. Each location is searched for a main config file or dropin patches under a `.d` directory or both (depending on the software's choice), and then considered in a defined order - later search directory roots have priority over earlier ones when the filename is the same, and dropins are considered in lexicographical order of filename regardless of which search directory they were found under. That said, it unfortunately doesn't go on to specify local-user overridability via $XDG_CONFIG_HOME etc, which might limit its adoption.