webkit2gtk: update to 2.38.0.

[oreo639]

[ci skip]

This splits webkit2gtk into 3 packages:

• webkit2gtk40: GTK+3 and libsoup2
• webkit2gtk41: GTK+3 and libsoup3
• webkit2gtk50: GTK4 and libsoup3

This is necessary since libsoup2 and libsoup3 cannot be used by an application at the same time. Ideally in the future, the packages using webkit2gtk40 would be moved to webkit2gtk41 or 50 (or be dropped).

I tested this PR with epiphany 42 and it seems to work (and it compiles sucessfully).

Testing the changes

• I tested the changes in this PR: briefly

[oreo639]

It is not standard practice to split the -devel package by functionality.

We do this with python2 vs python3 packages. We also do this with libportal, wxwigets, and libdbusmenu. This would also allow us to split the packages (i.e. if we get tired of building one of them constantly and decide we can afford to update it less frequently)

[ahesford]

Save the devel split for when it's needed, don't complicate the package structure in anticipation of something that may never happen.

[ahesford]

Actually, you're right; we shouldn't let the webkit2gtk-devel package pull in both gtk4 and gtk3. Please disregard my request to merge all devel packages.

[oreo639]

One blocker is that running webkit2gtk in sandbox mode results in the web processes being unable to connect to dbus, this seems to be an issue on other non-systemd distros, not sure what the cause of it is though. We were able to ignore it in the past, however the next release of epiphany will make it a hard error.

I don't run into that issue on flatpak though (i.e. the epiphany 43 flatpak on flathub).

Edit: the issue has been identified https://gitlab.gnome.org/GNOME/epiphany/-/issues/1852#note_1562896

[paper42]

We were able to ignore it in the past, however the next release of epiphany will make it a hard error.

If this is an error only with epiphany 43, then we don't have to fix it in this PR. This PR is holding quite a bit of updates, so it would be nice to get this merged.

[oreo639]

If this is an error only with epiphany 43, then we don't have to fix it in this PR.

TL;DR: webkit2gtk fails to connect to dbus since it disables networking in containers and the default dbus configuration uses tmpdir which on Linux (but not BSD) defaults to abstract sockets (although there is a PR in dbus to change that). It doesn't affect distros using the systemd user init because that overrides the settings to use the filesystem instead of abstract sockets. (This doesn't affect flatpak because flatpak creates its own socket path and uses it in the containers which webkit2gtk is supposed to do but doesn't)

This doesn't just affect epiphany.

https://bugs.webkit.org/show_bug.cgi?id=245843

There still isn't a solution upstream unfortunately.

[ahesford]

Can't the socket issue be fixed with a configuration change in dbus?

[oreo639]

Can't the socket issue be fixed with a configuration change in dbus?

Didn't work for me.

[ahesford]

In that case, I think we resolve this problem by adding an INSTALL.msg to the relevant webkit2gtk package(s) noting that sandboxed applications may require this configuration change and leave it at that. (If you want to provide more details, e.g. examples, install a README.voidlinux and have the INSTALL.msg refer to it.)

We don't need to anticipate and resolve any upstream changes that will break without configuration updates; that's the job of the user. (It would be nice if we could mark some updates as "manual intervention required" to force some critical notices to receive user attention, but alas, XBPS provides us no suitable mechanism.)

[oreo639]

Alright, it should be fixed now.

[paper42]

2.38.1 is released

[oreo639]

2.38.1 is released

Thanks. I tested it and it seems to work fine afaict.