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

Re: RFC: OpenRC as Init System for Debian

George Danchev wrote:
> On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> > 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

No, I didn't mix those up like that. I think you're referring to my
comment about Josh Triplett providing technical reasons to prefer using
etc-overrides-lib semantics, but Steve McIntyre's reply only mentioning
existing "set of tools" as a counterargument (which was silly given his
rpm comments). That was comparing the quality of their arguments, not
comparing etc-overrides-lib model vs dpkg functionality.

I didn't initially parse the "comparison" in your original post that
way, because it doesn't seem like a plausible way to read my original

> > 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 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.

> > 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.

Of course I do understand that include directives require application
support. I don't know where you got the idea that such directives would
be added by any automatic packaging helper; this is about how user
modifies configuration (use include+override rather than copy+modify).

Reply to: