3 ms·
Wouldn't a simple inotify[0] watch on /etc handle that scenario? Does it split up the commits by package? [0] http://linux.die.net/man/1/inotifywait http://lin
by jared314 13y ago
Wouldn't a simple inotify[0] watch on /etc handle that scenario? Does it split up the commits by package?
[0] http://linux.die.net/man/1/inotifywait http://linux.die.net/man/1/inotifywait
- NickNameNick 13y agoWouldn'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?
- jared314 13y agoThat 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]? [0] http://nixos.org/nixos/ http://nixos.org/nixos/
- ibotty 13y agoinotify 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).
- tankenmate 13y agoAcutally, 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.