On Wed, Sep 16, 2026 at 05:41:48PM +0200, Alberto Garcia wrote:
From here I think we have three different options:(1) Stop upgrading WebKitGTK and stick to the latest version that builds everywhere. CVEs would start to pile up and WebKitGTK would basically become dead downstream. (2) Stop building WebKitGTK on arches where it's not feasible (i.e. soon everything except amd64 and arm64, maybe more if Swift arrives to others). All reverse dependencies would need to disable WebKitGTK on the unsupported architectures (where possible). (3) Add a new src:webkitgtk-legacy package for unsupported architectures, with the latest version that works everywhere, and keep src:webkit2gtk up-to-date on the supported ones. For amd64 / arm64 users nothing would change, and other users would have to use a dead version of WebKitGTK with no security updates. I think that the worst one is (1), the easiest one is (2) and the best one is probably (3).
I don't think "use a dead version of WebKitGTK with no security updates" on release architectures is good tbh.
I think it a reasonable expectation for users of those packages on those arches, assuming they exist, to not be able to install software not supported by upstreams, especially when Debian cannot reasonably make it work.
In the case of QtWebEngine and other Chromium-based packages: Chromium stopped using WebKit more than 10 years ago and has a completely independent codebase. Therefore it's not affected by any of this.
I wanted to mention it, for a different angle:qt6-webengine 6.10.2+dfsg-5, the current version in sid, supports only amd64, arm64, armhf and i386.
-- WBR, wRAR
signature.asc
Description: PGP signature
