On Monday 28 September 2020 10:30:51 IST Thorsten Kukuk wrote:
Currently we have two directories with similar usage:
- /etc/default, seems to come from Debian, mainly used by upstream
projects on openSUSE
- /etc/sysconfig, mainly based on Red Hat, mainly used for start
scripts written by us. I will ignore the subdirectories here.
Both have files with in a KEY=VALUE format which can be sources by
/etc/default is controlled by RPM, so changes in the config files
lead to *.rpmsave or *.rpmnew files.
/etc/sysconfig is controlled by fillup. Adding new variables is easy,
changing defaults or removing variables is next to impossible in most
Why do I write this? No, I don't want to get rid of /etc/sysconfig,
but bring up an idea how to solve quite some of the problems with
updating sysconfig files.
Many bug reports about sysconfig files get closed as "Wontfix",
since changing defaults is really difficult, as we don't want to
overwrite user made changes, and adjusting comments is next to
impossible. As result, an user may have many sysconfig files with
outdated comments and content after a longer time after installation.
This can be very irritating or lead to not working configurations and
frustrations as following this steps does not lead to success.
Hey, we still have comments which tells the user that he has now to
run SuSEconfig because of this!
To run and manage our openSUSE containers via podman and systemd, we
started with as example for the bind container:
container-bind.service, which did contain:
and we run immeaditly into problems as there were typos in it which
we couldn't fix in an easy way on already installed systems.
But we have now /usr/etc and /usr/etc/default :)
So /usr/etc/default/container-bind contains now the system default
(fillup doesn't make sense here, as this file is RPM controlled and
should not be changed by an user), and the user can override single
variables by creating a file /etc/default/container-bind with just
this modified variables.
The container-bind.service looks now like:
All update problems solved without the need to find out, if a variable
is modified by an user or not.
This is not a proposal to change now all sysconfig files, but I think
many packages could benefit from such a change, especially if they
are really old and the sysconfig template gets often changed.
The packaging change is trivial: install the sysconfig template in
/usr/etc/default/, adjust your docu and remove the fillup call.
And you need to think about, if you want to rename the old sysconfig
file to *.rpmsave or move it to /etc/default.
Is this something we should propose as "best practise", or are there
reasons not to do so we haven't found yet?
Just to add some more context to the discussion
"Of course, there's one very good reason for supporting these files for a bit
compatibility for upgrades. But that's is really the only one I could come up with.
reason enough to keep compatibility for a while, but I think it is a good idea to phase
usage of these files at least in new packages."
Anyway, this text is old and is mostly the aspirations for systemd, but I guess is good
reading for understanding what systemd wanted to do about that.