On Thursday, December 14, 2023 12:58:02 AM MST Mike Gabriel wrote:
> All in all, I dearly welcome Soren's initiative on turning QtWebEngine
> 5.x and 6.x into rolling release packages inside Debian as the Morph
> Web Browser (morph-browser by package name) heavily will benefit from
> this.
>
> Responding to Qt core related thoughts only with this: Sticking with
> LTS upstreams is always a good choice for massive packaging projects
> (i.e. when many many packages are involved). This applies to Qt and
> KDE/Plasma I guess.
Qt WebEngine is a particularly difficult problem to solve as compared with other browser engines in Debian, because it is so intricately connected to so many other packages. In the case of Chromium, the latest full upstream release is just uploaded directly to stable-security and oldstable-security.
https://tracker.debian.org/pkg/chromium
In the case of Firefox, the ESR (Extended Support Release) is used, but that is only maintained for 15 months. When an old ESR is retired, a new one is uploaded to stable-security, oldstable-security, and old-oldstable-security, included all the new features.
https://tracker.debian.org/pkg/firefox-esr
They can do this because installing new feature releases of these packages does not break other packages.
WebKitGTK also uploads the current upstream version to stable-security and oldstable-security, including all feature updates. From what has been said in this thread, that is because upstream WebKitGTK is handled in such a way that these feature updates do not break compatibility with the GTK programs that incorporate WebKitGTK.
https://tracker.debian.org/pkg/webkit2gtk
Security support for Qt WebEngine does not enjoy this simplicity, which is why all previous discussions about how to manage security support in stable have ended without a fruitful resolution.
For all who have not already done so, I would recommend taking a look at the LTS release chart in the graphic at the top of this URL:
LTS releases are supported for 36 months and are released every 18 months. LTS point releases tend to drop about every 3 months.
I propose the following plan for security support in stable.
1. Always maintain the latest Qt LTS release in testing.
2. When stable is released, Qt WebEngine LTS point releases can be uploaded to stable. It should be possible to do this without updating the other aspects of Qt LTS in stable and without breaking all the KDE packages that depend on Qt WebEngine.
3. When the LTS in stable is no longer supported, security patches can be backported from the current LTS to the one in stable.
This sounds like a doable amount of security work and I would be willing to undertake it. I would be even more pleased to manage this as a team, especially when handling critical, time-sensitive vulnerabilities.
Given Qt’s LTS release schedule and how it will align differently with Debian for each release, this means that stable should have somewhere between 1-2.5 years of upstream LTS support (easy updates without backporting at Debian’s level).
This plan does not address oldstable security support. I would be willing to be involved with that if there were a team that wanted to share the load. Otherwise, we could modify the existing release security statement to inform users that there is no expectation of Qt WebEngine security support in oldstable.
The biggest downside to this plan is that it limits the recentness of the KDE software that can be included in testing and stable. So far, I have not been able to find good documentation showing what the minimum Qt dependency versions are for each release of KDE. Previously I discussed using KDE Plasma’s LTS release, but a better way to handle things might be to use whatever the highest KDE release is that can be built against the latest Qt LTS.
--
Soren Stoutner
Attachment:
OpenPGP_0x2D48F45A7EBE8C12.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature