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

[Tom Gundersen]

Hi Dimitrios,

On Sun, Dec 9, 2012 at 2:01 AM, Dimitrios Apostolou <jimis at gmx.net> wrote:
> from a reply I got to a bug report (FS#32817, reply is private) I found out
> that configuration files in /etc/conf.d are deprecated and that the
> supported way is to replicate and customize service files.

[...]

> So I'm curious to know why this mechanism was deprecated? Is it speed we
> gain by not including the EnvironmentFile directive in the systemd unit
> file? Is there some other reason I might be missing?

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.

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.

 * 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.

Cheers,

Tom