On 05/11/2018 09:24 AM, Ralph Corderoy wrote:
Quite often, these three data files appear,
/usr/share/icons/gnome/icon-theme.cache /usr/share/icons/hicolor/icon-theme.cache /usr/share/mime/mime.cache
triggered by /usr/share/libalpm/hooks. Based on the updated packages, I'm guessing a lot of the time the before and after content is the same, but the file has been re-created and moved in place of the old one anyway.
A cmp(1) could avoid the unnecessary churn, though I see it's more complex when an external command is exec'd rather than the re-build done directly. Even so, things like update-mime-database(1) used in update-mime-database.hook has a `-n' option that looks like it might often avoid the new inode.
-n Only update if MIME-DIR/packages/ or a file in that directory is newer than MIME-DIR/version. This is useful for package pre- and post-installation scripts.
Can churn be reduced? Or am I on the wrong track it detecting what needs to take note of new files?
The hook is only triggered when actual files from within there are updated by pacman. It's not run on every package transaction. As for wrapping it in cmp, the results are nondeterministic, AFAIK. I know for a fact /usr/share/applications/mimeinfo.cache is nondeterministic, it produces randomly sorted desktop entries which are extremely irritating since if you don't create your own program defaults in mimeapps.list then it will use the first one in mimeinfo.cache which changes every time you recreate the cache. (Lesson learned: set your own defaults even if it currently seems to work.) -- Eli Schwartz Bug Wrangler and Trusted User