Re: RFC: OpenRC as Init System for Debian
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"?
> 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.
> and files
> in /lib have no conffiles handling, after an upgrade you will not know
> what was changed by you and what was changed upstream.
IIRC dpkg does not store the original file (while ucf does), so
currently you always lose track of "what was changed by you" unless you
make a copy manually (or with extra tools like etckeeper). Anyway, this
is about the specifics of what is supported by Debian tools now, not
about any intrinsic problem with the behavior.
> 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?
Reply to: