Hey, At the moment there is a discussion in kde-core-devel, that distros won't ship QtWebEngine (at least Debian and Fedora). And ubuntu also will follow the decision of debian.
The only part so far, that depends on QtWebEngine in kdepim is KSieveUi::SieveEditorWebView it only shows links like: http://tools.ietf.org/html/rfc5173 (some people said, that these kind of links should be easy to display with a QText*) Regards, sandro -- Am Montag, 20. April 2015, 13:28:59 schrieb Lisandro Damián Nicanor Pérez Meyer: > Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to > the problem that QtWebEngine poses for us distros (in this case, at least > Debian and Fedora). > > I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a > hard (very hard) piece of software to package. > > It embeds quite a lot of 3rd party stuff which we distros don't accept (in > different grades depending on the distro) as we require to build using the > system versions. Fedora's Rex Dieter tells me that's actually why chromium > is not available for them. > > Moreover we can't build debugging symbols on most archs due to the enormous > amount of RAM+swap it involves in the linking process (more than 8GB last > time I checked). This is at least the same as QtWebKit, but seems to be > getting worse. > > Yes, we do understand that QtWebEngine is technically superior to any other > thing out there but making that code an acceptable package is another thing. > > So basically what I'm trying to say is: don't expect us down streamers to > easily package QtWebEngine soon, if we ever get to it. > > I'm really sorry if this comes as "bad news", but the reality is currently > this :( -- Sandro Knauß Software Developer Kolab Systems AG Zürich, Switzerland e: kna...@kolabsystems.com t: +41 43 501 66 91 w: https://kolabsystems.com pgp: CE81539E Sandro Knauß
signature.asc
Description: This is a digitally signed message part.
