OoO Peu avant le début de l'après-midi du vendredi 11 mai 2012, vers 13:20, Gergely Nagy <algernon@balabit.hu> disait : >>> In other words, it does *exactly* the same thing systemd is >>> criticised for. >>> >> >> Which doesn't mean that it's a good practice. > Tell me what you would gain, if there were no files under /lib/systemd, > and all of these were compiled into the binary, please. Because that's > the other option, as you *do not* let users change the defaults. You let > them override them, you let them configure the system. (And that *is* > being done in /etc.) > There are *very* few programs that come without any kind of default, and > even less, that let you change the default too. > apt does not let you change the defaults, nor does dpkg. Both allow you > to change their settings, but without recompiling, you can't change the > defaults. Same happens with systemd, the difference is that it's easier > to see the defaults, as they're broken out into files that are easy to > copy and change as needed. Yes, that's very true. We are just used that the kind of "defaults" in init to be in /etc. But nothing is set in stone. I was first against this etc-override-lib behaviour but your arguments are sound and I am now convinced that we should keep the way systemd is doing things. Moreover, in the case of systemd, there are other mechanisms that can be used to customize a configuration file for the more common modifications (handling dependencies and ordering) using symbolic links. This way, there is no need to copy the file from /lib in /etc to do the modifications. Still in the case of systemd, a README put in /etc/systemd may be used to explain the whole etc-override-lib to users that are not expecting such behaviour. A README is not a configuration file but there is one in /etc/init.d as well. -- Vincent Bernat ☯ http://vincent.bernat.im #if 0 2.2.16 /usr/src/linux/fs/buffer.c
Attachment:
pgpyWKB9ZKipx.pgp
Description: PGP signature