On Mon, Aug 14, 2023 at 03:47:42PM +0200, Martin Wilck via openSUSE Factory wrote:
On Mon, 2023-08-14 at 12:44 +0200, Jan Engelhardt wrote:
On Monday 2023-08-14 12:14, Martin Wilck via openSUSE Factory wrote:
Which makes it impossible for packages to install drop-ins in /usr if user edited file in /etc.
If the user placed /etc/xx.conf (rather than /etc/xx.d/xxx), they didn't want anything from /usr anyway.
I don't follow. Even if a user made some customizations in xx.conf, she may want still to follow package maintainer's customizations in /usr/lib/xx.d/.
No. If you wanted to follow package maintainer's customizations, you would use drop-ins (/etc/xx.d in my spelling), not a full config (xx.conf).
This assumes that every user understands and adopts the drop-in policy immediately. Also, it adds a non-obvious assumption about the user's intentions to the existence of the xx.conf file. More often than not, xx.conf will be a leftover from the past, created with no other intention than just modifying one specific setting.
The current scheme with both conf files and drop-ins in different directories is complex, but it has a concise logic: files in one hierarchy override files _of the same name_ in another. Your scheme further complicates this by adding a rule "file X in one hierarchy overrides file Y in another".
I can see that some admins may want to configure their systems in a way that no package-installed drop-in would ever override their own settings. But I think this must be achieved differently.
Whatever the design outcome, perhaps a systemd lint-like script to check the conf, drop-ins and whatever remnants of the past would be worthwhile? I always prefer following the breadcrumbs from verbose whingeing rather than tracking a trail from the corpses (#mondaymotivation). Daniel