[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian

Stephan Seitz <stse+debian@fsing.rootsland.net> writes:

> On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:
>>Neither the FHS, nor the policy says anything about etc-overrides-lib as
>>far as I can see. Neither pro or con. Do feel free to point me to the
>>relevant section, would I be mistaken.
> To be honest, I still don’t really understand what the files in lib are:
> - Are they configuration examples with all possible settings and their
> default values and the application works fine without these files?
> Then they should be in /usr/share/doc/<package>.

They are default settings for a particular service, and the application
does not work without them.

> - Or doesn’t the application start without these files? Then they are
> undoubtedly configuration files and according to FHS and Debian policy
> configuration files belong in /etc

It is indeed true, that these are settings the application does not work
without. So are many things under /usr/share, some of them similarly
configuration files (/usr/share/X11/xorg.conf.d/;
/usr/share/alsa/alsa.conf.d/ to name just two).

That a default happens to be in a file does not make it a configuration
file. A configuration file is something you *change* to alter a programs

With systemd, these files are under /etc. That the defaults are split
out into separate files is an implementation detail, nothing more. You
do *NOT* change the defaults. You change the settings.

>>The stuff in /lib are package defaults. Where the default is, in the
>>program, embedded, or in some file, doesn't really matter, it's an
>>implementation detail.
> It does matter. In the end it is the same situation as the firmware
> problem. For the hardware it doesn’t matter if the firmware is placed
> in an EEPROM on the hardware or loaded from the FS by the driver. But
> for Debian and its policy it is a difference.

Policy governs configuration. It never talks about default settings, it
does not mandate anywhere where and how defaults are to be set.

> So if you don’t want a default configuration from a file, because you
> don’t want to put a file in /etc, then you must compile the program
> with your default settings.

What happens if your defaults are open-ended? When you *can't* compile
them all in, because third party packages are able to extend the set of
default settings?

You can't compile in the defaults in that case. You could compile in the
subset shipped with the package, and you could make it so that third
party packages only use stuff in /etc, but that would needlessly
complicate matters for no real benefit.

>>worse - in some ways, even better - than some other existing practice
>>(the conf.d/ stuff I mentioned a few times elsewhere in this thread
> I like conf.d. It makes things easier for e.g. rsyslog or sysctl.

They also suffer from the very same problem the defaults in /lib/systemd
do. Namely, if you did not change the default, and it changes under you,
your system can break without any kind of warning or notice, and very
little trace as to what went wrong.


Reply to: