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]

[BillyONeal]

@ras0219-msft @MahmoudGSaleh @vicroms @AugP and I discussed this today.

Our understanding is that over time wayland usage will effectively replace X11 at some point, so this ends up being a judgement call on when that has happened.

If Wayland and X11 behave like "alternatives" in gtk, we must do exactly as #49571 did: features can't be alternatives so that would foreclose on making it a feature at all. However, the discussion in #49571 (comment) suggests that they don't behave like alternatives.

If it is a feature, then under https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#default-features-should-enable-behaviors-not-apis it cannot be a default feature.

[rkitover]

Apologies for being absent, I was in the hospital again.

So at some point we will need to clean up all of these ports to make Wayland support default dependencies, with an option to disable this with a custom triplet variable.

In the meantime, I will remove the default feature here.

[rkitover]

Default feature has been removed in this PR.

[rkitover]

For issues like this, I was thinking it would also be nice if we could have a config file for vcpkg to set global features, like Gentoo has USE in make.conf. E.g., add wayland to global features and it would be automatically enabled for any port with a wayland feature.

[AenBleidd]

@rkitover, this is possible to do through the feature testing: https://github.com/microsoft/vcpkg/blob/master/scripts/ci.feature.baseline.txt

[BillyONeal]

Apologies for being absent, I was in the hospital again.

:( Hope things work out for ya

@rkitover, this is possible to do through the feature testing: https://github.com/microsoft/vcpkg/blob/master/scripts/ci.feature.baseline.txt

That only affects our testing of the registry, it does not affect "ordinary vcpkg customers"

[BillyONeal]

Thanks for working with us and sorry we had to be inflexible on this point

Default feature was removed.

[AenBleidd]

Thank you for the update. Now this port with the defaulte features works perfectly fine.