install_steps: allow gtk_update_icon_cache to run gtk4-update-icon-cache

[cho-m]

---

• Have you followed our Contributing guidelines?
• Have you checked for other open Pull Requests for the same change?
• Have you explained what your changes do? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you explained why you'd like these changes included, not just what they do?
• For bug fixes, have you given step-by-step brew commands to reproduce the bug?
• Have you written new tests (excluding integration tests)? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) locally?

---

• AI was used to generate or assist with generating this PR.

---

Not sure on best way to handle different copies of update-icon-cache but this PR is one option.

There are a couple different alternatives, e.g.

• Use separate gtk3_update_icon_cache and gtk4_update_icon_cache DSL
• Add a parameter to gtk_update_icon_cache
• Splitting out gtk-update-icon-cache as separate formula similar to Linux distros (bit complicated to do in Homebrew).

Currently went with running any installed variant prioritizing newer copies. The cache command overwrites the same file so gtk3-update-icon-cache and gtk4-update-icon-cache should produce same results.

This avoids having to update formula when dependency changes.

Also may make it possible to collect multiple instances of gtk_update_icon_cache and try to run once. Would need to check if any scenario where another postinstall will need the icon cache prior to running though I'm guessing not likely given icon cache is for GUI usage.

[Copilot]

Pull request overview

Updates Homebrew’s install-steps runner to rebuild the GTK icon cache using GTK4’s gtk4-update-icon-cache when available, falling back to GTK+3’s tool otherwise. This improves compatibility when formulas depend on GTK4 without needing formula-side updates.

Changes:

• Adjust gtk_update_icon_cache execution to prefer GTK4’s gtk4-update-icon-cache when GTK4 is installed.
• Refactor test coverage to validate both GTK4 and GTK+3 behaviors for gtk_update_icon_cache.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Library/Homebrew/install_steps.rb	Chooses GTK4 vs GTK+3 icon-cache tool based on whether GTK4 is installed.
Library/Homebrew/test/install_steps_spec.rb	Adds targeted specs to cover both GTK4 and GTK+3 icon-cache execution paths.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Bo98]

Seems like something you'd check dependencies for (non-recursively ideally), and error out if it can't find any (or if it finds multiple). Most of the shebang stuff also works that way.

[cho-m]

Seems like something you'd check dependencies for (non-recursively ideally), and error out if it can't find any (or if it finds multiple). Most of the shebang stuff also works that way.

I was originally considered that but felt like it may be unnecessary overhead. Each update-icon-cache run overwrites the same file. Ideally we would run this once at end of install using any available command.

Just choosing latest is similar to how Meson post-install handles this, i.e. it will always prioritise an installed GTK4 command even if building app for GTK3 - https://github.com/mesonbuild/meson/blob/1.11.1/mesonbuild/modules/gnome.py#L353-L362

        if kwargs['gtk_update_icon_cache'] and not self.install_gtk_update_icon_cache:
            self.install_gtk_update_icon_cache = True
            prog = state.find_program('gtk4-update-icon-cache', required=False)
            found = isinstance(prog, Executable) or prog.found()
            if not found:
                prog = state.find_program('gtk-update-icon-cache')
            icondir = os.path.join(datadir_abs, 'icons', 'hicolor')
            script = state.backend.get_executable_serialisation([prog, '-q', '-t', '-f', icondir])
            script.skip_if_destdir = True
            rv.append(script)

[Bo98]

Ok, does that mean there's no functional difference between GTK3 and GTK4 versions? (I know you mentioned it overwrites the same file, was more wondering if the contents are the same too)

[Bo98]

Assuming the answer to the above is yes

[MikeMcQuaid]

Thanks!

[cho-m]

Ok, does that mean there's no functional difference between GTK3 and GTK4 versions? (I know you mentioned it overwrites the same file, was more wondering if the contents are the same too)

Should have no functional difference. I don't see any commits that would modify output contents.

On Linux side, Debian Trixie was able to remove GTK3 command and only ship GTK4 command:

• https://salsa.debian.org/gnome-team/gtk3/-/commit/87d7280ebf040987a3450e49c72c97b3ec3312c2

I also tried installing various formulae and check cache contents in container:

$ gtk4-update-icon-cache -f -t /home/linuxbrew/.linuxbrew/share/icons/hicolor
gtk4-update-icon-cache: Cache file created successfully.
$ mv /home/linuxbrew/.linuxbrew/share/icons/hicolor/icon-theme.cache icon-theme.cache.gtk4
$ gtk3-update-icon-cache -f -t /home/linuxbrew/.linuxbrew/share/icons/hicolor
gtk3-update-icon-cache: Cache file created successfully.
$ mv /home/linuxbrew/.linuxbrew/share/icons/hicolor/icon-theme.cache icon-theme.cache.gtk3
$ ls -l icon-theme.cache*
-rw-r--r-- 1 linuxbrew linuxbrew 5468 Jul  5 12:58 icon-theme.cache.gtk3
-rw-r--r-- 1 linuxbrew linuxbrew 5468 Jul  5 12:58 icon-theme.cache.gtk4
$ diff icon-theme.cache.gtk3 icon-theme.cache.gtk4
$ echo $?
0