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.
This follows directly from when you eliminate drop-ins from the picture and consider a system that uses just "full" config files. Like we used to in SUSE 6.x or something.
I don't remember 6.x, sorry. Martin