I've written some code to extend the VCS hook to provide more detailed log messages for post-install commits.
Basically, it matches the list of altered files against package manager file list and lists packages with actual configuration changes (plus non-package files) in addition to the list of all changed packages that's listed now.
I find it useful on large system updates, when the package list gets long and commit message consists mostly of irrelevant package names.
I have to note that I don't use package managers other than apt/rpm or vcs other than git on regular basis, so it would be useful if someone with more experience on those takes a look at mercurial/bazaar/darcs and pacman/pkgng implementations of the functions.
Patch for the post-install.d/50vcs-commit file is available at: https://gist.github.com/emkael/364f701a5342978e6e79c2368b905565
Good idea!
Reviewing the patch, I noticed that dpkg -S is run once per changed file. It should be faster to pass all the changed files to it, and parse the output.
(Other package managers may also be able to be optimised this way, but I only care about dpkg, and happen to know dpkg -S can be pretty slow.. rpm -qf may be fast enough that running repeatedly is not a problem.)
I think that the "Non-package (maintainer script/removed package) configuration files changed" list can be omitted. At least on debian there are unfortunately going to be a lot of such files, and it seems just added noise in the commit log, and added complication to build the list.
Please use tabs and not spaces for indentation, in keeping with the rest of etckeeper's code.
The per-file lookup was just a way to catch non-package files without too much hassle with splitting piped output.
Since that section is dropped, the updated patch provides lookup on one run of dpkg -S (and similar, for all package managers), plus some cleanup of the sort/uniq "post-processing".
The only thing I'm worried about is argument length limit - from what I was able to see, dpkg -S does not read arguments from stdin, so I'm just storing the file list in a variable. Is that much of a risk?
Just updated the previous gist: https://gist.github.com/emkael/364f701a5342978e6e79c2368b905565
Good thought about argument length limit. Use xargs?
There is a disturbing lack of quoting on
$FILELISTwhich I think could be a problem with filenames containing spaces etc. Using xargs with-d \nshould also avoid that problem.xargsshould do the trick. I've updated the patch or, if you prefer, pushed it to my local fork at:http://emkael.info/cgit/etckeeper/Seems I forgot all about this for 4 years, oops.
Good thing is, the patch still applied with only a few changes, so it's in, finally. Thank you.