Re: RFC: OpenRC as Init System for Debian
On Friday 11 May 2012 00:01:14 Uoti Urpala wrote:
--cut--
> > You need to at least start reading some man-pages (a good start would be
> > ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming
> > suggestion like "improvements to be able to alert the user about
> > changes". This is already there, and has been there for a long time, as
> > also mentioned before.
>
> I was talking about the etc-overrides-lib case; did you misunderstand
> that? Do those tools already have functionality which could be used for
> that case as is? If they do, I don't think it has been mentioned.
You can even do without any special tools for the applications following etc-
overrides-lib case, since at the end it all boils down to shipping the new
default configuration file in /lib, and warn them about potential updates. There
shouldn't be any merges involved, since this is the whole point of directory
separation.
Postinst's 'configure' stage:
* communicate a stock (default) configuration file in /lib
diff /usr/share/doc/foo/foo.conf /lib/foo.conf (or cksum them)
warn the user if the default (stock) configuration file has changed, send mail.
cp /usr/share/doc/foo/foo.conf /lib/foo.conf
* optionally handle locally modified /etc/foo.conf... we should leave it alone,
and not mess up with it, since this is a local admin setttings overriding
/lib/foo.conf as a whole or including it and overriding certain values only,
but anyway a simple call to ucf for completeness:
ucf /usr/share/doc/foo/foo.conf /etc/foo.conf
ucfr foo /etc/foo.conf
likewise, postrm, as shown in the man page.
Applications using more than one configuration file of effectively the *same type
and purpose* (since there applications with several configuration files, grouped
on different purposes) on startup would also cause the very same burden to the
admin mentally exesicing this very same process and guessing which was set
where and what overrides what. Not entirely pretty.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: