Hello, (sorry for being late, the last week was completely busy/crazy here) Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Exa mples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
I like that idea, and if it means that more applications start to support config file includes and whatever.d/* sniplets, I like it even more ;-) Even if implementing that config file handling probably isn't too hard - would it make sense to develop a library to read all the config sniplets and merge them? Maybe it could be based on the systemd code, but should be a standalone project to avoid another dependency on systemd, and to avoid that every project has to re-invent this wheel. Oh, and in the end, systemd could use that library ;-)
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
Sounds solvable with *.d/* files ;-)
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
These could be done via passwd.d/* etc. - either one file per user with username == filename (cleanest solution, but probably not the best idea when it comes to performance) or sniplets with as many lines as make sense for that file(name), with a "last one wins" policy. Note: system users don't come with guaranteed static uids, so packages will still need to run useradd in %post. Packaging a passwd.d/$username file won't work. Please avoid LDAP or other complex solutions. If a system is broken, you really want to have something you can fix with $EDITOR from a recovery system ;-)
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way.
Agreed, we should do this, and should coordinate it with all distros, FHS and the upstream projects.
2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed
I'd sum this up as "moving the default config to /usr/ will be an incremental and ongoing effort" (with a priority on packages included in MicroOS), and ...
- long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything
... this one is really a long term goal ;-) (years, not months)
3. We need to agree on a path below /usr for the default configuration files
I don't have a strong preference, but so far /usr/share/defaults/ and maybe /usr/etc/ look best to me. (If existing applications already use different directories for their default config files, they should move to the standardized directory sooner or later.) The layout inside /usr/share/defaults/ should exactly mirror the layout in /etc/.
Your comments and feedback?
I like the idea :-) Just in case you want to make your TODO list a bit bigger ;-) - I just noticed that you didn't look at /etc/alternatives/ yet. Currently we have several /usr/bin/whatever, /usr/share/man/whatever symlinks pointing to /etc/alternatives/ - we'll need to find a solution for that too. (I don't have a good solution for that - symlinks don't support fallbacks, and letting update-alternatives change the symlinks in /usr/ is also a bad idea. Nevertheless, I wanted to make sure you have this on your radar.) Regards, Christian Boltz -- It's hard to learn how to ride a bike on the road while watching someone else do it from the sidewalk sitting on your trike :) [David C. Rankin in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org