[webkit-dev] Introducing a minimum ICU version for WebKit

[Michael Catanzaro]

On Thu, Apr 9, 2020 at 7:08 pm, "Olmstead, Don" <Don.Olmstead at sony.com> 
wrote:
> Hi Michael,
> 
> There are a couple problems with checking in a version of ICU.
> 
> * Other libraries used by WebKit have dependencies on ICU. For our 
> ports harfbuzz, libxml2, libxslt, libpsl and CFlite all require ICU.

You're right, it's a bad idea.

> * ICU doesn't come with a CMake build system and its non-trivial to 
> make one. We've largely used this 
> https://github.com/LibCMaker/ICU_CMake_Files to handle building ICU 
> but its use is also why ICU is the library we aren't able to update 
> on a regular cadence.

Another good point. Hadn't thought that through far enough.

> * We aren't terribly good with updating things in ThirdParty. 
> Sometimes this is because there aren't releases, see gtest. Others 
> because they don't actually have releases, see ANGLE. On top of that 
> there might be local modifications to make things work within WebKit.

Of course, bundling things in ThirdParty is an absolute last resort. 
But when using system packages is no longer possible, what else to do? 
I have to support WebKit on RHEL 7, which has ICU 50. Mike from SUSE is 
trying to support SLE 12, which has ICU 52. You can see it doesn't add 
up. :)

But I didn't object to the ICU 60 proposal because (a) our dependency 
policy allows cutting off distros older than Ubuntu 18.04 and Debian 
Buster, and (b) I figured we would just bundle it. Instead, a better 
approach is probably to come up with downstream patches to revert all 
the changes that require ICU 60 and maintain them as long as we can. 
Same goes for CMake, but it's going to get a lot harder as WebKit usees 
more and more new CMake features. At some point we'll probably need to 
try bundling a custom CMake, since eventually that will be easier than 
patching WebKit to use ancient CMake.

> Could you possibly give some overview of how WebKit is packaged by 
> Linux distributions? I would have thought they would use 
> flatpack/jhbuild to get the dependencies that the WPE/GTK ports are 
> using especially if those dependencies have their own set of bug and 
> security fixes. My experience with Linux is minimal so some context 
> here would be appreciated.

No, distros build against their own system packages.

JHBuild is a developer tool. And flatpak is cool, but not used to build 
distro packages. Fedora is experimenting with distributing applications 
using flatpak, but you can't distribute system libraries that way.

> For our ports we use vcpkg to build and manage dependencies. We host 
> it at https://github.com/WebKitForWindows/WebKitRequirements and have 
> an internal fork for PlayStation. I'm guessing it's probably similar 
> to flatpack/jhbuild in terms of functionality but in our case we just 
> use GitHub releases to have binaries ready.
> 
> Perhaps there are better ways for us to approach the requirements 
> that would be beneficial to all ports?

I don't think there's really anything to do other than to decide how 
many old distros we're willing to cut off of updates. Currently the 
dependencies policy protects distros for three years. To continue 
supporting Ubuntu 16.04 (which reaches EOL in April 2021), it would 
need to be extended to five years. Probably not many developers would 
be very happy with that at all. But Ubuntu have a five-year lifecycle, 
so it's tough beans for WebKit users if we drop support before that 
time. RHEL and SLE have 10 and 12-year lifecycles, respectively... 
nobody is going to propose supporting that upstream, we just have to 
either figure out how to deal with it or cut off updates eventually 
once it becomes too hard to build.

I'd support extending our dependencies policy from three years up to 
five years... only problem is, five years makes it really hard to use 
new C++ features, and we like those. :( Anyway, with the current 
dependencies policy, ICU 60 is allowed. We'll just have to figure out 
how to deal with it downstream.

Michael