On Saturday, December 16, 2023 4:53:48 PM MST Patrick Franz wrote: > > Qt WebView is deprecated upstream. It was based on the same Apple > > WebKit source that WebViewGTK uses. It was replaced quite a while > > ago by Qt WebEngine, which is based on Google’s Chromium. There is > > no Qt 6 version of Qt WebView, so it will go entirely away at that > > point. > > There is one: https://tracker.debian.org/pkg/qt6-webview > > Are you perhaps confusing Qt WebView with Qt WebKit ? Yes, that was exactly my confusion. Sorry for reading it wrong. Qt WebView is the QML wrapper for Qt WebEngine. And there definitely is a Qt 6 WebView. > Usually, we try to avoid packaging the private headers. But for some > packages, we just need to. And that's because other packages depend on > them incl. other Qt submodules. > We don't have a rule set in stone, but we usually package private > headers when either another Qt submodule needs them (e.g. qtwebview > needs the private headers of qtwebengine, hence we package them) or when > important KDE components need them (e.g. qtwayland). Looking at the list of private header files that ship in qtwebengine5-private- dev, these all relate to the Qt specific bindings on top of the Chromium source code (these are the Qt specific APIs that are then translated into Chromium calls). None of Chormium’s private headers are exposed, meaning that none of the private headers that are involved in the rendering or processing of websites are included. It is nearly unthinkable that any of these Qt specific headers would be modified by a security update. So, it should generally be possible to ship Qt WebEngine LTS updates without creating any problems for packages that built against these private headers. -- Soren Stoutner soren@stoutner.com
Attachment:
signature.asc
Description: This is a digitally signed message part.