On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote: > Steve McIntyre wrote: > > Josh Triplett wrote: > > >Marco d'Itri wrote: > > >> The more I think about it, the more I suspect that the correct > > >> solution would be to just symlink /lib/udev/rules.d/ to > > >> /etc/udev/rules.d/ and so on. > > > > > >Please don't. As a user, I find it highly preferable for packages to > > >install their default configuration in /lib and just have overrides in > > >/etc, and I'd love to see that trend continue. That setup lets me > > >trivially construct personal configuration packages that ship the > > >overriding files in /etc, without having to play ugly games with > > >dpkg-divert of conffiles. It also means that I don't get a pile of > > >noise in etckeeper from all the upgrades of default configurations, so > > >that my commits to etckeeper primarily consist of my own local changes. > > > > 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. > 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. 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. 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 > Who's the one choosing his preferred configuration format based on the > limitations of his preferred packaging system here? Hint: it's not Red > Hat. You're good, but I'd better watch Peter Sellers, honestly. -- 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/201205101802.37898.danc...@spnet.net