[arch-general] On /etc/conf.d deprecation

[Dimitrios Apostolou]

Tom, thank you very much for the extensive reply, I've been searching a 
lot for the reasoning you explained.

On Sun, 9 Dec 2012, Tom Gundersen wrote:
> Speed is not a concern.
>
> The way things should ideally work, IMHO, is:
>
> 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, as I pointed in my example such options should be hardcoded in 
ExecStart. Unfortunately this comes with the side-effect of missing any 
updates if ExecStart gets customised in custom unit file (I didn't know 
about systemd-delta, thanks to everyone who mentioned it).

>
> 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.
>
> 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 to whatever is used upstream (maybe the Debain location, or maybe
> the Fedora one, or maybe something else, it would probably differ from
> package to package). I think it is better to have a general rule
> saying "we don't use /etc/conf.d with systemd", than package by
> package moving their config files around as things are upstreamed.

Personally I believe all distros that switch to systemd will add their own 
twist to it. Distro-independant Unit files sounds like Utopia. In reality 
I expect unit files to be patched for various custom needs of different 
distros. But anyway if it is actually achieved it would be great.

> * most packages have their own configuration file where some, if not
> all, options can be configured. Having two locations for configuring
> the same options is not ideal, so we want to avoid that to the extent
> possible. One could imagine using /etc/conf.d for packages where not
> all command-line options can be configured in the config file.
> However, 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.
>
> There are cases when using /etc/conf.d is necessary, but to the extent
> possible we should try to avoid it. Moreover, the first option should
> always be to petition upstream to add their own config files with the
> required options, and only if that is impossible add /etc/conf.d
> support.

Just let me be specific with two examples that I use /etc/conf.d, and it 
may be more clear why they are still needed:

1) On a memory constrained system I use the following for spamassassin: 
SPAMD_OPTS="-c --min-spare 0 --max-children 1 -s local5". I don't think 
this can be customized by other means.

2) For the crond started service of sysstat, I keep all history with 
HISTORY=9999 in /etc/conf.d/sysstat. I don't know if /etc/conf.d is being 
deprecated for everything or only for systemd started daemons, but this is 
a non-systemd example that makes good use of it.


Thanks,
Dimitris

>
> Cheers,
>
> Tom
>