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

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

Don Armstrong <don@debian.org> writes:

> On Thu, 10 May 2012, Gergely Nagy wrote:
>> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
>> do something *very* close to what etc-overrides-non-etc does. To the
>> point that changing a file under /etc/default, or adding a snippet
>> to conf.d/ can break just as well when the underlying default
>> changes as if that upstream happened to be outside of /etc.
> That's true. I suspect that much of conf.d/* and default/* are a
> consequence of the lack of easy 3-way merge support in dpkg. But
> that's kind of an orthogonal issue.

I don't think that is so. It's also there to allow other packages to
drop snippets there. Modifying another package's conffile would be
against the policy, so conf.d/-style snippets are the obvious solution.

Nothing to do with the lack of merge in this case. Even if dpkg gains
fabulous merge support that never fails, ever, conf.d/ will still be
used because we need the ability to add snippets from unrelated

>> Except it's easier to follow, since the default is never modified
>> by the admin, while if it's in /etc too, like in plenty of cases in
>> the archive, both can change, and we end up with even scarier
>> situations that can't be resolved sanely.
> I'm unable to follow. In the etc-overrides-non-etc case, we would be
> increasing the number of cases where we had copies in /etc and in
> non-etc.
> If things were just in /etc, they wouldn't be in non-etc, and you'd
> only have one copy in all cases.

True, if the non-etc stuff were simply copied, we'd have a single
copy. With all the disadvantages that brings, like not being able to
override the default from another package, as that would mean we have to
modify a configuration file.

In the case of systemd, you need to be able to override the default from
another, unrelated package. At least for things like the syslog

At the moment, systemd has /lib/systemd/system/syslog.service, which
starts the journal. If I want to override that, I need to override the
syslog.service, which is done by placing a file in
/etc/systemd/system/syslog.service (whether a symlink, or a file,
doesn't matter; the syslog daemons in debian place a symlink).

If we didn't have etc-overrides-lib, how would you do this? How would
you make it able to override a single service, from another package?
Play dpkg-divert tricks? Or use conf.d/-style stuff?

The latter suffers from the same issue etc-overrides-non-etc suffers
from, the former makes it much harder for admins to override services,
and I don't like the idea of dpkg-divert'ing config files all over the
place either..


Reply to: