Discussion:
Less Modified Files from Updates.
(too old to reply)
Eli Schwartz via arch-general
2018-05-11 13:58:48 UTC
Permalink
Raw Message
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
Loading...