On 08/02/2022 16:57, Michael Catanzaro via webkit-dev wrote: > Hi, > > I'd like to selfishly propose updating our dependencies policy > https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy in order to > accommodate RHEL in addition to Debian and Ubuntu. My goal is to provide > WebKitGTK updates for the first five years (the "full support" period) > of a RHEL major release, not just three years. However, we have some > magic I don't understand allows use of newer toolchains, including newer > libstdc++. We can actually somehow link newer libstdc++ into the same > process as system libstdc++, so we can exempt the entire build toolchain > (including CMake) from this policy, so this won't have any effect on > discussions like "when can we use C++20 features" or "what version of > CMake can we depend on." > > The primary impact would be on dependencies like ICU, GStreamer, etc. > ICU is particularly important because this library bumps its ABI with > every major release, so updating ICU to newer major versions is not > possible. This would lock us into supporting ICU 67 until spring 2027. > If we decide to land https://bugs.webkit.org/show_bug.cgi?id=235367 -- > which currently looks unlikely -- then it would additionally lock us > into ICU 60 until spring 2024. > > I think five years' support would benefit Ubuntu as well -- this matches > the primary support lifetime of an Ubuntu LTS -- except Ubuntu doesn't > seem to have the capability to build with newer toolchains, which means > that, in practice, they will stop updating WebKit whenever we require a > newer build toolchain. And although I think it would be a good idea to > support Ubuntu for longer, I'm not brave enough to propose that we > freeze our build toolchain dependencies for five years. So I will not > suggest extending the support period for Ubuntu. > > Specifically, I propose adding the following text to our policy: > > * "We support the latest minor release of each major version of RHEL > until two years after the release of the next major version." > > (Note: we currently have a three-year time-based release cycle, so > that's five years total. If that were to unexpectedly change in the > future, then adjusting the text of the policy would be needed.) > > And: > > * "For RHEL, WebKit is not expected to remain buildable using the > default system libstdc++. The requirement for WebKit to remain buildable > may be satisfied using GCC and LLVM toolsets from Application Streams."
If I understand this correctly, that would mean that we would have to support the libraries that we rely on, up to a version that may be quite old. Right now we are supporting a cycle of 2+1=3 (both debian and ubuntu release each 2 years). And this change would mean that we would have to extend the period up to 3+2=5 which is quite more. I think this may cause tension in the future regarding supporting the usual GNOME libraries that move fast: GTK, GStreamer, etc To give some data, the last version of RHEL is 9 (released on Nov 2021) which means that we would support RHEL 8 up to Nov 2023. And RHEL 8 was released on May 2019 and includes this versions of libraries we use: gstreamer = 1.16 gtk = 3.22 glib = 2.56 libsoup = 2.62 cairo = 1.15 icu = 60.3 Personally I'm ok with this, since I usually error on the conservative side regarding updating dependencies. But I'm raising the topic to put things into perspective and to help having a debate. Also if we are going to do this, and we are serious about it, then we would need at least two new buildbots at build.webkit.org for testing the build on the last two versions of RHEL. Is RedHat going to provide the resources for the bots and is going to help taking care of things when they broke there? _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
