Hi, On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote: > I am sympathetic to the principle that we should support the > compilers that ship on the most popular versions of Linux.
Great. :) > I’d like to understand if that argument is sufficient to support GCC > 4.8. > > Can you clarify, is it the case that if I installed the latest stable > Fedora, I’d get GCC 4.8? No, all currently-supported versions of Fedora include GCC 5 (only). Different distros have very different release cycles and policies for compiler upgrades. Fedora releases roughly every six months, and each release is supported for roughly 13 months. GCC releases once per year. The GCC developers coordinate with Fedora release planning to time GCC releases to coincide with spring Fedora releases; in the winter before a new GCC release, we rebuilt all of Fedora with the GCC beta so the GCC developers can collect bug reports. So we will never have issues with Fedora, as the oldest Fedora will be at most one year behind upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and I'm making sure all supported Fedoras get updates.) But Fedora is exceptional in this regard. Other distros are supported for much longer than 13 months (5 years for Ubuntu LTS and newly also for Debian, 10 years for enterprise distros) and therefore have much older compilers. The question is where do we draw the line. We obviously cannot support a 10 year old distro; those are maintained by rich corporations, and if they cared about WebKit security, they could take responsibility for that. We could handle 5 years, but do we really want to? (It's clear Apple doesn't.) It's really inconvenient to not have access to newer dependencies or language features for so long. We might start by saying that we only support the latest release of [list of major distros that have recently been shipping WebKit updates]. Most of these distros are currently built using GCC 4.9, though they might have GCC 5 or GCC 6 packaged as well, but not used by default. The big one still using GCC 4.8 is openSUSE. We don't *need* to consider Ubuntu right now, because they rarely ever take our updates, nor Debian, because they never take our updates. I think WebKit updates for Debian is all but totally a lost cause, but I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind. Also, different distros have different policies on using alternative compilers. E.g. in Fedora we are usually required to always use Fedora's GCC, and only one version is available at a time... but if a package *really* has no chance of being built with GCC, we're allowed to use Fedora's Clang instead. I'm not sure what the policies are for Debian and Ubuntu, but they always have available a newer GCC than is used for building packages, and until recently were using Clang to build Chromium, so alternative compilers must be permitted at least in exceptional cases. I was trying to convince the openSUSE folks to use Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not enthusiastic. (But consider that all these distros will have older versions of Clang as well.) Now, whether openSUSE is important enough on its own to justify holding back or lowering our GCC requirement... maybe not. But anyway, since we have significant contributors like Konstantin stuck with GCC 4.8, and since this doesn't require giving up on any significant language features, I think it's OK. If it's only a little work to support that compiler (on the level we already have in trunk), I think it's a good idea. But there is another problem here. openSUSE seems to have no intention of upgrading to a newer GCC anytime soon, because they have started to inherit core packages like GCC from the SUSE enterprise distro. So I might need to negotiate with them if it would be possible to build WebKit with clang after all. > Can you clarify what you mean by “backport”? I’m trying to get a > picture of how your releases work. For example, are you saying that > RHEL wouldn’t take a security update that you backported, or that > they won’t invest energy into backporting it themselves? We don't try to convince distros to take individual security fixes as patches, because there are way too many for that to be practical. We want them to take our tarball updates. In that mail I was saying that RHEL won't invest energy into backporting things themselves downstream; consider that we have about 100 security fixes per year, backporting from trunk needs to be handled upstream so this can be shared among distros, rather than separately by each distro that wants to provide WebKit updates. Our upstream WebKitGTK+ releases work like this: every February and August, we branch off of trunk; this forms a new stable branch, which gets released in March/September. We then cherry-pick fixes to that branch and make releases off of it for the next seven months or so. Our goal is to convince distros to take these releases, because it's the only practical way for them to get security updates. I've recently had some mixed success with this; a couple big names like Mageia and openSUSE recently started taking our updates. Some distros like Debian refuse to take any version upgrades at all, and want to fix everything with downstream patches. Since that is not practical for WebKit, they have adopted a policy of no security support for WebKit. Ubuntu leans towards this as well, but occasionally they do take our updates; I'm hoping that might become more common. (RHEL is a bit of a special case in that its old enough that all apps in RHEL are using WebKit1, which we don't support anymore, so there's no value in taking our updates.) > How many changes are required to make GCC 4.8 work? I think this > will provide important context for this discussion. I guess it's working already and we only need to remove the build error when it's detected, because Konstantin has been committing GCC 4.8 fixes throughout the tree: http://trac.webkit.org/search?q=4.8&noquickjump=1&changeset=on Anyway, I do not strongly request that we drop the GCC requirement to GCC 4.8, though I think that would be fine; just please, we should keep these issues in mind when upgrading our compiler requirement in the future. Michael _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
