gtk{2,3}{,-devel}: Use GTK3 version of gtk-update-icon-cache by default

[qwertychouskie]

Description

If building a port that needs to run gtk-update-icon-cache, but gtk2 is no longer installed, the port will fail to build. This is because gtk3's gtk-update-icon-cache is currently renamed to gtk-update-icon-cache-3.0 to not conflict with the gtk2 version. This PR makes it so the gtk2 version is renamed to gtk-update-icon-cache-2.0, and the gtk3 version keeps the default name of gtk-update-icon-cache. GTK2 is long deprecated, the list of things still using it is shrinking over time, and therefore the likelyhood of having a build fail due to gtk-update-icon-cache missing is going to keep going up if we depend on the gtk2 version being installed. In fact, as I get to updating more XFCE stuff, the list of things depending on gtk2 is going to get even smaller.

FWIW, on my Ubuntu system, gtk-update-icon-cache is installed as a separate package, and is built from the GTK3 sources. There does not appear to be a gtk2 version of this binary even available.

See #23674 (comment) for an updated build that is broken by the old behavior.

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 14.4.1 23E224 arm64
Xcode 15.3 15E204a

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint --nitpick?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[macportsbot]

Notifying maintainers:
@mascguy for port gtk2-devel, gtk2, gtk3-devel, gtk3.

[mascguy]

Converting to draft for a few days, until I've had a chance to test with dependent ports. (Otherwise it might get merged at the 72-hour mark, and these ports are critical.)

[kencu]

and about 77 ports have already been configured to use gtk-update-icon-cache-3.0 now, so all those will presumably have to be changed if this is done:

https://github.com/search?q=repo%3Amacports%2Fmacports-ports%20gtk-update-icon-cache-3.0&type=code

[kencu]

not to mention that gtk-update-icon-cache-4.0 will be the new kid soon enough... wouldn't it be nice if there was a "fix this once" approach to some of these things that didn't require redoing the same work over and over...

[qwertychouskie]

not to mention that gtk-update-icon-cache-4.0 will be the new kid soon enough... wouldn't it be nice if there was a "fix this once" approach to some of these things that didn't require redoing the same work over and over...

It doesn't look like GTK4 has a gtk-update-icon-cache binary. Hopefully this change is just one-and-done.

[qwertychouskie]

and about 77 ports have already been configured to use gtk-update-icon-cache-3.0 now, so all those will presumably have to be changed if this is done:

https://github.com/search?q=repo%3Amacports%2Fmacports-ports%20gtk-update-icon-cache-3.0&type=code

Is it best to update one port per commit or have one supercommit updating all the ports?

[mohd-akram]

This would be nice to have. I think one commit is fine in this case since it’s all the same change.

EDIT: Actually, two commits. One for gtk-update-icon-cache -> gtk-update-icon-cache-2.0, and one for gtk-update-icon-cache-3.0 -> gtk-update-icon-cache.

[mascguy]

This would be nice to have. I think one commit is fine in this case since it’s all the same change.

The following comment summarizes the key concern with this PR:

#23674 (comment)

[mohd-akram]

I don't think a find and replace is a lot of work tbh. It's also used in the activate stage AFAIK so no rev-bump needed. And we get rid of a bunch of patches.

[reneeotten]

@mascguy please take care of this PR and the few that depends on it. If nothing happens in the next week, I will start closing them.

If you don't want to merge them, that's fine with me. But just say so and close the PR(s) instead of having them open without any intention to get them merged.

[qwertychouskie]

@reneeotten @mascguy I finally had a good chance to address updating all the Portfiles for applications that call gtk-update-icon-cache to call the correct versions (gtk-update-icon-cache-2.0 for GTK2 apps, gtk-update-icon-cache for GTK3 apps). This PR should be ready to merge.

[mascguy]

@reneeotten @mascguy I finally had a good chance to address updating all the Portfiles for applications that call gtk-update-icon-cache to call the correct versions (gtk-update-icon-cache-2.0 for GTK2 apps, gtk-update-icon-cache for GTK3 apps). This PR should be ready to merge.

There's another gotcha that you need to deal with: Users routinely have both GTK2 and GTK3 installed. And when that's the case, you have a problem: These updated ports will try to overwrite the gtk-update-icon-cache binary of the other port. So MacPorts will correctly fail to install the update, due to that conflict.

So we'll need to add the so-called "deactivate hack," deactivating the other port prior to activation. But it should only be done for the previous version/revision.

Let me know if this makes sense. I can also dig up a reusable tcl procedure, which I've used previously for such a case.

[qwertychouskie]

I can also dig up a reusable tcl procedure, which I've used previously for such a case.

That would be perfect. Alternatively, I do have maintainer edits turned on for this PR, so you could commit it directly yourself it you prefer.

[qwertychouskie]

@mascguy Any update? Perhaps another route would be to make the new revision of gtk3 conflict with the old revision of gtk2, so the gtk2 update will always get installed first (if MacPorts' dependency resolution works like that). Would that work?

[qwertychouskie]

I can also dig up a reusable tcl procedure, which I've used previously for such a case.

@mascguy I just wanted to check on this since it's been over a month with no response. Other updates are pending this PR being merged (e.g. #24851), so I'd like to get this finished and merged as quickly as possible.

[mascguy]

@mascguy I just wanted to check on this since it's been over a month with no response. Other updates are pending this PR being merged (e.g. #24851), so I'd like to get this finished and merged as quickly as possible.

Here's our documentation for the deactivation logic, which includes a good example.

For your purposes, you'll need to check for two ports: Both the regular one, and -devel.

Take a look, and let me know if it makes sense.

Sorry, forgot the link:

https://trac.macports.org/wiki/PortfileRecipes#deactivatehack

[reneeotten]

so is anyone going to work on this and resolve it anytime soon? If not, I am going to close the PR and the ones that depend on it.

You can always reopen them once you had the time to work on it - the PR queue isn't here to park unfinished PRs for extended periods of time.

[qwertychouskie]

so is anyone going to work on this and resolve it anytime soon? If not, I am going to close the PR and the ones that depend on it.

You can always reopen them once you had the time to work on it - the PR queue isn't here to park unfinished PRs for extended periods of time.

I can probably finish it this weekend now that I have been provided the information needed to finish it.

[qwertychouskie]

Alright, I believe this should be ready to be merged now.

[reneeotten]

@mascguy as the relevant maintainer please take care of this PR

[qwertychouskie]

@mascguy Any chance you could take a look at this PR and merge it if everything is good?

[qwertychouskie]

Rebased onto latest master.

Are there any plans to merge this? I have other port updates that are waiting on this PR being merged, and I'd like to get these upstreamed soon so my local state isn't constantly diverged from upstream.

[mascguy]

Are there any plans to merge this? I have other port updates that are waiting on this PR being merged, and I'd like to get these upstreamed soon so my local state isn't constantly diverged from upstream.

Definitely, but I need to carve out some time to validate these changes locally.

I'll try to get to it this week, if possible.

[reneeotten]

@mascguy this has been open now for more than 6 months; anytime would be good now or I will close the PR