Re: RFC: OpenRC as Init System for Debian
Philip Hands <phil@hands.com> writes:
> On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
>> Marco d'Itri wrote:
>> > On May 10, Bjørn Mork <bjorn@mork.no> wrote:
>> >
>> > > Agree. Copying a large set of default policies into /etc just because
>> > > they *can* be overridden is not user friendly. And it does not make the
>> > > defaults any more configuration either. It just hides important local
>> > > changes and makes it difficult both for the user and the application
>> > > itself to distinguish between defaults and configuration overrides.
>>
>> > Wrong:
>>
>> You're not addressing what he said about the generally desirable /etc
>> semantics at all, only talking about what current Debian tools would do
>> without modifications. Do you have a reason to oppose beyond "this would
>> need some tool changes"?
>
> Yes -- it scatters configuration state outside /etc (thus hiding it from
> etckeeper and sysadmins alike), it makes the packages surprising to
> people familiar with Debian but not familiar with the package (Hint: we
> have a _lot_ of packages -- nobody is familiar with all of
> them. Requiring people to become familiar with all the packages before
> they can safely do an upgrade is part of what explains the number of
> rotting RedHat systems I see than nobody is brave enough to upgrade).
I'll turn this around: how do you handle cases where the defaults of
packages like apt, exim or syslogd change? Where the defaults are
embedded in the executable.
You don't. That systemd has the defaults in files under /lib is an
implementation detail. It's no different than any other default other
software comes with, except that this one is easier to see and notice
when it changes: it's possible to craft a trigger that'd fire in those
cases.
It's not possible to do that for cases where the default is hidden,
which is the case for the vast majority of software. Yet, I do not see
anyone jumping on those, and demanding they move *all* their defaults to
/etc.
>> > since you have to copy the whole file to override it,
>>
>> Wrong: as mentioned in this thread before, one of the advantages of the
>> etc-overrides-lib model is the option of having a file in /etc that
>> first includes the one in /lib, then overrides just one particular
>> value. This allows handling more updates without needing manual changes,
>> as you can automatically pick up other updated values while keeping the
>> override, without needing to do 3-way merges.
>
> This is the real problem with the etc-overrides-lib approach. For a
> sysadmin to know what to expect from a particular set of configuration
> files they need to be intimately familiar with the package in question,
> and why the change was made. Does the package allow partial overrides
> with includes or otherwise? Is the existence of an empty file deeply
> significant (think the udev persistent net thing). Did some default
> appear in lib that needs to be carried into etc? etc. etc.
The same could be said of various conf.d/-style hacks that plague the
archive. Do snippets override the things they change, or do they get
merged? One must be familiar with the particular program to figure it
out.
This problem exists in every piece of software that can be configured,
and does not use a single monolithic configuration file.
> The traditional Debian approach to /etc is largely self documenting, to
> the extent that one can generally walk into a site cold and (having
> established that they have decent backups) cheerfully do an upgrade on
> their Debian servers without anything breaking (I do this regularly).
I'm afraid my experience disagrees, see above: the conf.d/-style hacks
vary between packages, and there is *no* common ground. Some override
settings completely, some get merged, it largely depends not only on the
package in question, but in the setting aswell: even within a package,
some settings get merged, some get overwritten.
Sometimes it is even an error to try and override parts of the main
configuration within a snippet - and you can't tell that only by looking
at the files. You have to know the software in question, and how its
configuration works.
etc-over-lib is no different to existing practice. The only difference
is where the defaults live, nothing else.
> The sources of potential breakage are highlighted by the packaging
> system, at which point you can read up on any package that needs
> attention with which you're not already familiar, while ignoring the
> ones that upgrade cleanly.
Like I said elsewhere in the thread: conf.d/-style snippets. They're
widely used, show the same problems. etc-over-lib is no worse.
> Having exceptions to that is deeply unhelpful, and the more exceptions
> we accumulate the less maintainable and upgradable Debian becomes.
etc-over-lib is no exception. It's configuration in /etc, that overrides
or changes default. Like *every* other piece of configuration that is in
/etc. Where the default is, doesn't matter.
We *never* get notification when defaults change, unless the default is
explicitly laid out in /etc and the software itself comes with no
defaults at all, which is rarely the case. It's not the case with exim,
nor any of our syslogds, it's not the case with apt, nor dpkg.
Our best source of notification about these are NEWS files and
changelogs.
etc-over-lib has no disadvantage over this existing practice. It does
have the advantage of making the defaults visible.
> Your assert that etc-overrides-lib is technically superior
Personally, I believe neither way is superior in general. There are
cases when one's more suitable than the other, though. I believe, that
for systemd, etc-overrides-lib is superior. It wouldn't be for something
like the syslogd or your MTA.
>> > Obviously this is not a problem for Red Hat since they do not support
>> > upgrades between major releases.
>>
>> Why would this cause problems for Debian, except at most needing some
>> changes to tools to better support this case? Or do you think
>> implementing that would be hard?
>
> Are you volunteering to do that?
>
> If not then stop making assertions that simply require someone else to
> do a load of work to pander to your unusual tastes. If you are
> volunteering, then that's somewhat better (although I would prefer
> that we simply fix the packages to behave themselves in a proper Debian
> way instead).
Then please fix all the conf.d/ things too, and everything else that can
change its default without notice, while there.
--
|8]
Reply to: