George Danchev wrote: > On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote: > > Steve McIntyre wrote: > > > No, really - please *do* do this. The fact that a lot of the software > > > coming out of RedHat development seems to be designed solely for their > > > use, including working around the missing/broken features of RPM, is > > > seriously annoying. Configuration belongs in /etc, we know this. We > > > have a well-designed and implemented set of tools in Debian based on > > > that standard. > > > > Machine-specific configuration belongs in /etc. The default behavior of > > the tools doesn't. > > For some reason or another the vast majority of applications have not been > following this approach. I'm not going to argue whether is makes sense or not.
The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. > > Josh Triplett provided multiple technical reasons why etc-overrides-lib > > is preferable. The ONLY technical reason you gave to prefer traditional > > conffiles was that there already is a "set of tools" for that in Debian. > > Your comparison is misguided. Which comparison are you talking about? From your following text it seems you mean the comparison between 1) criticizing Red Hat for (allegedly) letting packaging system limitations affect the choice of configuration format and 2) saying Debian should choose its preferred configuration format based on the limitations of its packaging system, though that comparison does not appear in the text you quoted. > The vast majority of applications do not follow etc-overrides-lib (some will > never follow) so their configuration files should be properly managed as > well, > and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with > things like ucf and debconf are quite powerful mechanisms to employ which > have > been proven for the last decade. Contrast this to the rpm systems trashing > locally modified configuration files in /etc/ for the last decade. It is also > trivial for the debian packages to contain default configuration files so > users > and tools could refer to them on demand, and this has nothing to do with the > packaging system itself. 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. I don't think it makes the above comparison any less valid. And generally, I don't think the packaging system issues would be so difficult that they should have a major influence on what configuration model to use. > OTOH, applications following etc-overrides-lib happily run on Debian systems > in the way they run on others. It is not like the semantics of separating the > default and locally modified configuration files in two directories is some > sort > of giant invention, never heard of before. It is also trivial to guess that > their configuration files could also be managed by calling tools from dpkg's > maintainer scripts in order to communicate with the user or provide > assistance Yes, nobody has brought up reasons why this wouldn't work. -- 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/1336668798.2227.58.camel@glyph.nonexistent.invalid
