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). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336683674.2227.138.camel@glyph.nonexistent.invalid
