The cool thing about Etckeeper is that it plugs directly into your package manager. If you're using deb or rpm, a commit is made after each package install if they changed /etc.
Ah! Now there's a reason to look through the source code. I've being wanting to make update scripts for online projects that are not in my distribution's repositories. (I'd love it if GO updated when I told my computer to update).
small nitpick, it does not hook into dpkg and rpm but into apt and yum (there are surely hooks for other package managers). so when you install a package without these higher level package managers, it does not get recorded...
inotify consumes resources (ram), which a hook into a package manager does not. you cannot watch all subdirectories within /etc with one handle, so you will have to recursively setup handles for all subdirectories. then, you might run into the max_user_watches limit (see sysctl fs.inotify.max_user_watches).
Acutally, using fanotify() you can watch a whole filesystem with one watcher; use FAN_MARK_MOUNT (inotify and fanotify both use the fsnotify subsystem in the kernel). So then you set a watch on either /etc (if it is separately mounted) or watch / and then ignore any paths that aren't in /etc.
Wouldn't that commit as soon as any file was changed, no matter who or what changed it, denying users the ability to supply a meaningful commit message?
That depends on the filesystem events you tie into (Open, Close, Write, Delete, etc) and what your responding script does. But, at the point where you want to put the entire system under some kind of change management, why not use something designed for that, like NixOS[0]?
