Re: RFC: OpenRC as Init System for Debian
Philip Hands wrote:
> 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).
If you walk into a site cold, how do you tell if they have weird local
configuration for something? It's much easier to check if there's
something under /etc than to start checking whether the files match
what's expected for the package version, if the the default files are
always there even if nothing has been configured.
> 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.
And why would this have to be any worse with etc-overrides-lib?
> > 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).
No, I'm not volunteering, mainly because I don't want to program in
shell (which ucf seems to be implemented in). I can still estimate what
such an implementation would need to do. You can't argue that everything
which has not already been implemented would be a huge fundamental
problem. If you want to argue that etc-overrides-lib would be
fundamentally bad, hard to support, or undesirable to even try to
support in Debian, then you should say more about implementation
difficulties than just "it's not implemented at the moment".
George Danchev gave a proposed implementation of change alerts in an
While there are things you'd want to improve in a "real" implementation
for packager convenience and better user interface (and the ucf part
looks like it'd incorrectly create the file under /etc by default), I
think that's enough to demonstrate this is not a particularly hard