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

Re: RFC: OpenRC as Init System for Debian



On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don't see how that's
> > > relevant to the discussion.
> > 
> > The reason why it is relevant is because
> 
> I don't see how the following would make this comparison with rpm relevant.

It was a comparison of the packaging system facilities to handle upgrades of 
the configuration files of the applications. This was initially started by you 
as a misguided comparison between etc-overrides-lib (apples) vs. dpkg conffiles 
(oranges). Basically you're mixing up packaging system facilities to handle 
upgrades/transitions of application configuration files with the styles of 
applications reading their own configuration files.

> >  in the etc-overrides-lib
> > 
> > model you are unable to trivially merge local changes with upstream or
> > packaging changes unless you add additional logic in the postinst to
> > handle etc-overrides-lib. Having configuration files in /etc and using
> > ucf or similar enables you to deal with this problem easily.
> 
> Yes, you do need some tool improvements to be able to alert the user
> about changes. This has been mentioned before. I don't think this would

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'm pretty sure that merging techniques could be made even more smarter or, 
but "alerting the user" functionality has been there for a long time already.

> be hard to add though, and not overall harder than what is already
> implemented for traditional conffile handling; this is not a fundamental
> problem with the etc-overrides-lib model.
> 
> And as also mentioned before, the include option should reduce the
> number of cases where you need to do 3-way merging.

You don't seem to understand that style of reading of configuration files of the 
applications is in the realm of the applications themselves and packaging 
systems facilities which help handling upgrades of these application 
configuration files can not frivolously add "include" or any other convenient 
option directives you are suggesting to these application configuration files.

-- 
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>


Reply to: