Distros and QtWebEngine

Milian Wolff mail at milianw.de
Mon Apr 20 22:02:35 BST 2015


On Monday 20 April 2015 13:28:59 Lisandro Damián Nicanor Pérez Meyer wrote:
> 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 :(

Have you notified the Qt WebEngine developers about this? I have not seen any 
email in that regard to the official upstream mailing list at qtwebengine at qt-
project.org .

Previously, many of the 3rd party stuff was just hardcoded and shipped 
internally because it was easier to get stuff done. Now with things settling a 
bit, afaik one could start working on the build system to use a system-
provided version of "the 3rd party stuff". Some stuff will probably always be 
shipped internally, but at least this could help things a bit. In all cases, 
its sadly sometimes simply not possible to make different FOSS code work 
together without custom patches for a certain project. Yes, this is against 
the ideal utopia we all dream of, but with limited man power there will always 
be problems like this.

Regarding debug symbols, it certainly works with ld as others have mentioned.
And it is definitely easier to build than QtWebKit.

Anyhow, I won't judge distros when they won't package software that is against 
their principals. But I hope you guys also understand that for some developers 
a good solution for some people is better than a half baked broken solution 
for some more people. I'm not a KDE PIM maintainer, but with my KDevelop hat 
on (that uses a web view to display documentation pages, currently QtWebKit), 
I could understand a projects decision to just make a certain feature 
optional. Certainly less maintenance effort than supporting different 
implementations.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150420/a6b629cd/attachment.sig>


More information about the kde-core-devel mailing list