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

["Jérôme M. Berger"]

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 at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20121210/8b0b83df/attachment.asc>