On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote: > 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.
Implying that a fairly simplistic semantics of providing two distinct directories with configuration files, has never been considered for the last 40 years and painting it as a revolution in the application development is naive, at best. > > > 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, Let me tell you a secret: Debian should not decide whether or not tens of thousand of applications follow a particular style of reading their configuration files. This is in the realm of application development and anyone should be free to choose their style. It would be a segregation if Debian bans applications simply because their style of reading configuration files looks funny... and Debian does not segregate. This is not a secret. > 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. What I was saying, I already wrote. Retelling it wrong is useless. > > 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. Now, the hard work remains: teach all applcations out there to follow the etc- overrides-lib _semantics_. Sure, thing, I'm thrilled, at all. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- 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/201205102103.19021.danc...@spnet.net