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