[arch-general] Less Modified Files from Updates.

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180511/b5e69939/attachment.asc>