Bump Weston's Meson requirement

We have quite some things waiting for a Meson version requirement bump:

• #180 wants Meson 0.50
• #269 (closed) is waiting to be released in Meson: https://github.com/mesonbuild/meson/pull/5775
• #293 (closed) would want Meson 0.49
• #289 (closed) might benefit from Meson 0.50
• #295 needs Meson 0.50.1

Could we bump the requirement and how far?

If we go for 0.50 or later, I have a vague recollection that we should pick a 0.x.1 at least for some fixes.

added Build system label

You really would need to update to Meson v0.49, because undef stuff doesn't work as Weston expects in v0.47 (#293 (closed)). Rest of the listed issues seem more like nice to have, not hard fails with current git Weston code?

• Ubuntu 18.04 LTS has v0.45.1: https://packages.ubuntu.com/bionic-updates/meson
• Ubuntu 19.04 has v0.49.0 (which works in 18.04): https://packages.ubuntu.com/disco/meson
• Debian stable has v0.49.2: https://packages.debian.org/stable/meson

(Debian testing and latest Ubuntu 19.10 have Meson v0.51 or newer.)

What about CentOS / RHEL / Fedora and other major distros?

changed the description

mentioned in merge request !388 (closed)

I'd like to bump the requirement for Wayland to meson >= 0.50 for wayland!68 (merged) as well.

Limiting upstream projects to what is available in Debian stable is... very limiting. For the distros themselves, if they wish to include Wayland/Weston that requires a new version of meson, they'll backport Meson. FWIW, Michael Biebl (the Debian developer who did the Meson 0.49 backport) told me that he did it for systemd. For users, it's trivial to install Meson via pip.

I don't think it makes sense to severely limit the Meson version requirement.

I don't think it's super severe; 0.50 is less than a year old? Is there no workaround at all for what we're facing?

closed

mentioned in merge request wayland!68 (merged)

reopened

I didn't mean to close this earlier, just pressed the wrong button.

Do we want to keep on being conservative in what Meson version we require (being careful of when and how far to bump), or should we just use whatever Meson version suits us regardless of any distributions?

Developers and CI can easily use an upgraded Meson. Do we actually need to care about distributions?

I would like the same policy to apply to Wayland as well.

wayland!68 (comment 429778) seems to suggest keeping conservative. What would be the rules then? Limit to the version shipped in current stable distributions but backports allowed?

Saying we care about the distribution versions of Meson raised some eyebrows on #mesonbuild IRC.

We support wayland-scanner older than 1.14.91, GBM versions older than the API shipped with Mesa 17.1, and xkbcommon older than 0.5.0 (2014). If we're raising the Meson build dependency to something shipped last year, then we should probably drop all the others as well, and say that we just require whatever latest version of whatever we depend on.

Personally I would be fine with all that up to some degree, but I also make a difference between build-time-only and runtime dependencies. Does that difference exist for distributions?

Upgrading Meson specifically is trivial for developers. Developers upgrading libs beyond what your distribution-at-hand provides can get annoying if there are many.

For what it's worth, I emailed the debian-backports@ list and asked if we could get a newer backport. Jussi replied and said he doesn't have upload rights, but that that would be fine with him. (https://lists.debian.org/debian-backports/2020/03/msg00006.html)

Since I believe I may have voiced an opinion in this area, I just want to clarify: I don't care about buildsystem changes that might be awkward for a distribution, like bumping the meson version to something newer than whatever's in RHEL 7.ancient. But the reason I don't care is that we've already solved that problem for our own build pipeline, and that if we hadn't I'm paid to suffer that kind of pain anyway. I don't want to imply that upstreams shouldn't care about distribution workload, just that they needn't care about Fedora-family distros for my sake.

I'd like to clarify that I don't really care about distribution workload, because that's the job of distributions. What I care about is, given that we have very short support cycles, not making it needlessly difficult for end users (including people deploying products) to upgrade. Partly that's out of empathy for them, but also that's trying to reduce our support load, by giving people no excuse to not be running latest upstream.

If you have a look through Weston bug reports lately, you'd be surprised how many of them are back on 1.x or 2.0.

Right, I can fully agree to that on the runtime dependencies.

Here we are talking about the build system though, and Meson specifically. Would depending on the latest release of Meson cause similar amount of pain as depending on some fresh library at runtime?

From a reply to my mail to debian-backports@ requesting newer Meson (https://lists.debian.org/debian-backports/2020/03/msg00010.html):

I re-read your email and found it a little bit confusing. If Wayland and GTK upstream are explicitly not using newer meson because Debian stretch and buster does not have newer meson, please do me a favor and tell them to go ahead and use the features provided by newer meson, do not get limited by Debian's version decision.

Debian's buster-backports now has meson 0.52.1: https://packages.debian.org/buster-backports/meson

But, @mattst88 mentioned that some of the CI infrastructure might be using the oldstable/stretch (released June 2017), rather than stable which is currently buster (released July 2019). If that is the case, maybe updating CI to buster and enabling the backports repo would be something to consider?

I'm not going waste another breath trying to convince anyone to do anything with regards to this topic, but in case it is decided that raising the requirements are worth it, I've made wayland!70 (merged)

The only reason we're on stretch rather than buster is just that we never had a reason to move yet.

Only leaving this here because a Debian developer asked me to:

https://lists.debian.org/debian-backports/2020/03/msg00015.html

Since Debian 10 ("Buster") already has meson 0.52, can you help to forward the discussion happened at https://lists.debian.org/debian-backports/2020/03/threads.html to Wayland/GTK upstream and ask them to feel free to raise the bar of Meson requirement (to at least 0.52)? From the Debian side, we sincerely do not want to block the development of upstream projects.

Really, we have no reason to keep on using Stretch in CI.

Also, we are not blocking Meson bumps because it might cause work for Debian packagers.

The reason I am asking if we can and how far we can bump Meson dependency is the users: there are people who are for reason or another stuck with particular version of Yocto, RHEL, Ubuntu, or something totally homebrewn. I presume such users exist and that they would be very annoyed having to upgrade Meson - I have heard enough complaints about Weston's runtime library dependencies before, and also about the move away from autotools. But since I do not have personal contacts to ask, I am asking here, hoping someone would know or have a contact to ask.

The reason I am asking if we can and how far we can bump Meson dependency is the users: there are people who are for reason or another stuck with particular version of Yocto, RHEL, Ubuntu, or something totally homebrewn. I presume such users exist and that they would be very annoyed having to upgrade Meson - I have heard enough complaints about Weston's runtime library dependencies before, and also about the move away from autotools.

Yes, this is what I have been trying to say previously. I'm not worried about distributions themselves, or our CI pipeline (yes just use Buster; as above the only reason we use stretch now is because it was current-stable when we introduced it and we haven't had a reason to switch since). What I'm worried about is raising the barrier to people trying newer code. I don't have specific contacts for people who would have difficulty, just from what I've seen over bug reports / mail / IRC / etc.

I think bumping to Meson 0.52 is fine, as distributions are carrying it, and you can trivially install it out of pip as well. Relying on an unreleased version doesn't make any sense however.

So sure, let's just go to 0.52 for both, and Buster for our CI.

Weston CI is using Buster since 8a171adc.

mentioned in merge request wayland!70 (merged)

mentioned in merge request mesa/mesa!4740 (merged)

Since meson 0.54 is in Debian now, #269 (closed) is now blocked on bumping the dep in weston.

Buster (Debian stable) is at v0.49.2, but buster-backports has 0.52.1. Latest Ubuntu release, 20.04 LTS released few weeks ago, has v0.53.2. Fedora 31 has 0.52. Bullseye (Debian testing) and recently released Fedora 32 updates include Meson v0.54.

Considering Ubuntu and its derivatives, bump to v0.52.1 was couple of weeks too early, but is fine now. I think bumping the Meson version further is too early, with one of the most used distros and its derivatives not having new enough Meson.

mentioned in merge request wayland!104 (merged)

mentioned in merge request wayland!105 (merged)

mentioned in commit pq/weston@eb7a14a3

mentioned in merge request !550 (merged)

mentioned in commit pq/weston@c0565b61

closed with commit c0565b61

mentioned in issue wayland#236 (closed)

mentioned in merge request !732 (merged)

mentioned in merge request !1127 (merged)