gtk3: move Wayland support to default feature

[rkitover]

Make the Linux Wayland support a default feature instead of a hard dependency so that it can be disabled if wanted.

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[rkitover]

@AenBleidd @dg0yt

[AenBleidd]

Hm, that's strange: I specified to build gtk3 without default features, but it was still trying to build it with wayland:

• Test updated gtk3 vcpkg port BOINC/boinc#6816
• https://github.com/BOINC/boinc/actions/runs/21369249514/job/61509193173

Need to investigate whether this is an isue on my end or with the vcpkg port configuration itself...

[rkitover]

How did you try to install it without default features? The way to do that generally is to install gtk3[core].

[AenBleidd]

@rkitover. I specify this in my config file:

        {
            "name": "gtk3",
            "default-features": false
        },

[BillyONeal]

I spoke with @AenBleidd about this over Discord. The reason he is seeing gtk3[wayland] get turned on is that he has a top level dependency on wxwidgets, which has dependencies: [....... , "gtk3", ....]. That means wxwidgets depends on gtk3[default] which drags in gtk3[wayland].

This is why our default answer is that by default things should not be default features ( https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#default-features-should-enable-behaviors-not-apis ); people find turning the defaults off next to impossible in practice. #49571 retoractively added a dependency on gtk3[wayland] to (at least) appstream-glib, elements, libui, opencv3, qtbase, and wxwidgets as none of these declare "default-features": false.

[rkitover]

Ok, so I will explain why I made this a default feature, and I will turn it off if you disagree.

• Just about every distribution now ships with Wayland and Wayland librariesw, even OpenBSD, even when some proportion of users are still using X11.
• Every developer (the target audience for building ports) will have the dev libraries for Wayland installed, either explicitly or as a dependency of something.
• Every distribution ships the GTK3 libraries with Wayland support.
• It does not affect the runtime behavior of GTK3, it will run on both X11 and Wayland and this is also configurable.
• It's not possible to even detect Wayland with GDK without the Wayland support, because the gdkwayland.h header is missing, so for example my app did not even compile.

You guys have a Discord? Can you give me a link?

[AenBleidd]

However, with this change you change the backend to Wayland, meaning that you are changing the behavior to all the users of the gtk3 port, and the majority of them might not even be aware about thus breaking change.
I was able to detect this behavior change on the very early stage because I use the clean environment without any wayland libraries.
After thinking about this for a while, I would say, that any hevaior change like this should not be a default feature, but rather 'opt-in' feature as it was suggested by @dg0yt before.
I would also agree on 'opt-out- feature but then this will require changing all the ports that have a gtk3 dependency no not use default features by default.

You guys have a Discord? Can you give me a link?

We usually speak in PM, so the link won't be helpful.

[BillyONeal]

You guys have a Discord? Can you give me a link?

To be clear there isn't anything meaningful that happened here, it was just going back and forth questions to arrive at "oh, the dependency came from wxwidgets". There was no kind of "policy" discussion or similar; normally I just get pinged that macOS is broken for some reason this way 😢 .

[BillyONeal]

• Just about every distribution now ships with Wayland and Wayland librariesw, even OpenBSD, even when some proportion of users are still using X11.

This seems a good reason to make the change but then I'm not sure why it is a feature at all. (That is, wayland would always be a dependency and no feature configuration could take it away) @AenBleidd How does it 'break' you?

[AenBleidd]

I have a clean build with no system libraries. I build everything using vcpkg (including x11 libraries).
When I tried to build the same way wayland, I found out that the build is actually broken:

1. wayland (or wayland-protocols I don't recall exactly) depends on libxkbcommon but never declares it
2. gtk with wayland was failed to build due to the executable failed to be found:

Program wayland-scanner found: NO

../src/NOME-gtk-3-f64471d55d.clean/meson.build:716:22: ERROR: Program 'wayland-scanner' not found or not executable

See detailes in the attached archive.
linux-package_logs_manager_amd64_4c96819d933c97c9cfa7f7644516a6d0ecbaea3e.zip

Just about every distribution now ships with Wayland and Wayland librariesw, even OpenBSD, even when some proportion of users are still using X11.

I do not have a list of distributions that actually ships Wayland and Wayland libraries. I maintain an application that should be able to run on very ancient OSs (I have a list though), but I have no idea how can I reliably test my application (or at least the availability of Wayland) on all of them.
Again, backend for gtk3 has been changed with the previous PR, hat means that the behavior of every application that relies on gtk3 in one or another way has been changed as well, meaning that it need to be retested to avoid any runtimes issues.

As for me, this is too risky to make this feature a defaule feature, expecially after we found out that there is no easy way to opt-out from using it.

[AenBleidd]

PR for the reference is anyone is interested: BOINC/boinc#6811

[rkitover]

Again, backend for gtk3 has been changed with the previous PR, hat means that the behavior of every application that relies on gtk3 in one or another way has been changed as well, meaning that it need to be retested to avoid any runtimes issues.

There is no change in behavior, the Wayland backend support does not affect running on X11.

However, an app linked to the static GTK3 will still need to be dynamically linked to the Wayland libraries. So if you need to build a mostly static binary to run on some very old distribution without Wayland libraries, that would be a problem.

But in that case you are likely to have other problems, like the version of glibc.

[AenBleidd]

There is no change in behavior, the Wayland backend support does not affect running on X11.

I do not agree on that.
This looks like a breaking change to me:

if("wayland" IN_LIST FEATURES)
    list(APPEND OPTIONS -Dwayland_backend=true)
else()
    list(APPEND OPTIONS -Dwayland_backend=false)
endif()

However, an app linked to the static GTK3 will still need to be dynamically linked to the Wayland libraries.

No, if you bild everything statically (I do admit that even the static build might require some client support for application to run like the support of Wayland on the particular OS).

So if you need to build a mostly static binary to run on some very old distribution without Wayland libraries, that would be a problem.

This is exactly my case.

But in that case you are likely to have other problems, like the version of glibc.

No, if you build on the oldest OS you support (in my case this is Debian Buster, however I use it for the particular version of glibc to build with, and I do not know if all the other distributions that has this version of glibc support Wayland (and what is more important, have it installed)).

[rkitover]

There is no change in behavior, the Wayland backend support does not affect running on X11.

I do not agree on that. This looks like a breaking change to me:

There is no change in runtime behavior, nothing is broken.

However, an app linked to the static GTK3 will still need to be dynamically linked to the Wayland libraries.

No, if you bild everything statically (I do admit that even the static build might require some client support for application to run like the support of Wayland on the particular OS).

It is not possible to make completely static binaries on Linux. Some libraries have to be linked dynamically. When people do this, things like X11 and Wayland generally fall into that category.

So if you need to build a mostly static binary to run on some very old distribution without Wayland libraries, that would be a problem.

This is exactly my case.

So you have an edge case that is broken by other ports, as opposed to the default port being broken for everyone who expects Wayland support, which is present in every current build of GTK3.

@BillyONeal You decide this, I will remove the default feature if you want.

[AenBleidd]

It is not possible to make completely static binaries on Linux. Some libraries have to be linked dynamically. When people do this, things like X11 and Wayland generally fall into that category.

I do have a GUI application that required X11 but have as much as possible built statically without direct dependencies.

$ readelf -d $(which boincmgr) | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libnotify.so.4]
0x0000000000000001 (NEEDED) Shared library: [libnsl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libatomic.so.1]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]

[vicroms]

As @AenBleidd has experienced, default features are hard to disable because every downstream consumer must specify default-features: false.

Given that, I think the cleanest solution here is to add the feature but not make it a default feature.

[BillyONeal]

Does that mean we should also effectively revert #49571 ?