Tom Gundersen wrote: > Options related to the init-system, such as where the lock-file is > located should be indicated as an option in ExecStart. The reason this > makes sense is that it must match what is specifid in PIDFile=. The > same goes for any other option that systemd requires to be a certain > value to function correctly. All these options are things that the > admin would not usually change. > Agreed. > However, options that are unrelated to the init-system should not be > specified in ExecStart=, but should be configured in the applications > own configuration file. It has nothing to do with systemd, so for > systemd to just stupidly read it from one location and pass it on to > the program without touching it seems wrong on a conceptual level. > Conceptually, you are right. Unfortunately not all applications work that way today, so we need a way to pass the options to the applications that don't. > More concretely, why we should avoid /etc/conf.d (and why all distros > should discourage similar use of their own config directories): > > * it is distro-specific, so once we switch to unit files provided by > upstream, we would have to change the location of the configuration > file ... > > * most packages have their own configuration file [...], what do we > then do when one day the config files are extended > to deal with all the options? If we drop /etc/conf.d support we'll > have the same problems as above: package by package changing > behaviour. > From time to time, a package update requires changes to the configuration. This would only be one more such time. Moreover, the problem is the same once someone has customized the unit file. OTOH the /etc/conf.d file could be marked as a config file in the package and therefore go through the pacnew/pacsave mechanism on updates. Today, most Arch users are used to checking for pacnew/pacsave files regularly so they would spot the change as soon as the /etc/conf.d file got removed from the package and a .pacsave appeared in its place. Jerome -- mailto:jeberger@xxxxxxx http://jeberger.free.fr Jabber: jeberger@xxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
