gtk+3: update to 3.24.21.

[ahesford]

Also add dependency on adwaita-icon-theme because GTK applications will not display properly without at least some icon theme; see void-docs PR #396. The appropriate response is to pull in the default theme, then let users ignorepkg if they wish to replace it with something custom.

cc: @Gottox (maintainer) @flexibeast @ericonr

[ahesford]

Update: adding a dependency on adwaita-icon-theme will create a build dependency cycle because that package depends on librsvg, which depends on gtk+3-devel to build.

I cleaned up the adwaita-icon-theme template here, noticing the the package builds exactly the same without any of the hostmakedepends I removed. Also, the flag in configure_args is no longer recognized by the configure script.

The last change is to remove librsvg from depends to break the build cycle. adwaita-icon-theme provides SVG versions of its theme and I understand that librsvg will be needed to support the scalable theme. However, I believe this support is optional and maybe shouldn't trump the availability of a default theme as a hard dependency on gtk+3. Also, I'd argue that the requirement to be able to read SVG files rests not with the theme that provides them, but with the package that reads the them.

If dropping the librsvg dep is unacceptable, we have no choice but to drop the adwaita dep from gtk+3 and will always have the problem that gtk+3 programs may not display properly by default.

[ericonr]

Having tried this on my system, I got:

• pavucontrol, without adwaita, doesn't have icons
• pavucontrol, with adwaita but without librsvg, shows the proper icons, but prints a warning about being unable to load a pixbuf from an SVG file
• nwgbar (from nwg-launchers, not yet packaged), without adwaita, doesn't have icons
• nwgbar, with adwaita but without librsvg, crashses with SIGABRT due to being unable to load pixbufs from SVG. This is likely caused by not having a fallback

Therefore, I think what we need to do depends on the themes we currently ship. Are there themes that only ship PNGs? If not, we could make gtk+3 depend on librsvg, because:

most gtk applications need adwaita theme to work properly -> some applications crash when SVG icons exist but they can't load them -> gtk should depend on a library to load svg icons OR those applications should depend on librsvg

I'm in favor of solving it for gtk+3, because otherwise all applications will still print warnings when using PNG icons, and tracking down applications that misbehave is time consuming and error prone. Furthermore, librsvg is a small package compared to gtk+3.

[ahesford]

Having gtk+3 depend on librsvg would be the best solution, but it isn't realizable because librsvg depends on gtk+3-devel and would create a build-time dependency cycle.

I may explore breaking this cycle. Maybe splitting Adwaita into separate PNG-only and SVG-only themes would allow GTK to depend on the PNG-only themes that would work everywhere, with users having the option to install the SVG theme if they were interested.

We could also just discard the SVG files to provide a basic functional PNG theme for GTK, then tell users we don't package SVG for the same reason we are refusing to package other themes.

[ahesford]

Okay, I think I found a workable solution. Apparently librsvg only depended on gtk+3-devel because older versions used to provide a simple SVG viewer, but this [was dropped[(https://people.gnome.org/~federico/blog/removing-rsvg-view.html) some time ago. I bumpbed librsvg and removed the gtk+3-devel dependency so there should be no cycle if gtk+3 depends on librsvg for proper support for scalable themes.

adwaita-icon-theme now has its usual librsvg dependency, but most of the build-time dependencies in that template were removed because the build outputs don't change with or without them.

gtk+3 now has a runtime dependency on librsvg (to support arbitrary themes that offer SVG) as well as adwaita-icon-theme to provide basic functionality out of the box.

@ericonr, if you wouldn't mind, build the packages in this PR when you get a chance and confirm correct behavior for pavucontrol and nwgbar.

[ericonr]

All is good in GTK-land with your PR, thanks! I hit a weird segfault with rustc, but it built fine the second time :D

[ahesford]

At the recommendation of @ericonr, I'll ping @pullmoll and @fosslinux to help me avoid any dependency cycles. I manually read through the dependency tree and don't believe I saw any cycles back to gtk+3, but want to be extra sure.

[fosslinux]

I'll just need to check the new dependencies that have been added, gtk has been fine for a few months now.

[Chocimier]

No new cycles found with https://gist.github.com/Chocimier/de76441493ec7775c201dac0bb03ced5

[fosslinux]

No cycles

[ahesford]

@Chocimier @fosslinux thank you both