On Sun, Jun 09, Christian Boltz wrote:
Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb
Application configuration files:
Do something similar to what systemd is already doing today (See
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
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?
We are already working on that ;)
/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.
I created a PoC for this already. The glibc NSS plugin was easy, but
adjusting all tools to be able to change the password or other data
(chfn, chsh, ...) is pretty much work. And the worst is, it does not
even solve any of our problems on systems with transactional-updates.
You would still use an UID or GID twice.
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 ...
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)
I'm not that sure. We did already some changes for MicroOS only
in the past (like moving from cron to systemd.timer, and suddenly
everybody was modifying his packages, too.
But yes, it will take a long time and I'm pretty sure some applications
will never be adjusted.
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 see a real problem with /etc/alternatives, it's in the end
user configuration. Yes, it's not strictly seperated into system defaults
and user changes, but in the end, that's defined by the database.
At least I haven't found yet update problems with it.
But a real problem with update-alternatives is /var
There, we really mixed up everything and this does currently not work
with transactional-updates (not even really with snapshots and rollback).
I assume you're referring to /var/lib/alternatives? If openSUSE
switched to the version of alternatives shipped in chkconfig, we
could probably make adjustments to the implementation to deal with
this problem. I don't see the Debian guys wanting to change this in
their implementation, because they don't care about this problem.
It probably makes sense to move it to /usr/lib/sysimage/alternatives,
actually. I could easily package this up and make it a drop-in
replacement for what we have now in SUSE distributions.
真実はいつも一つ！/ Always, there's only one truth!
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org