QtWebEngine Poses Problems For Debian, Distribution Vendors

Debian and other Linux distributions are running into issues with packaging up QtWebEngine, which is becoming a problem since more of the new KDE stack is becoming dependent upon this addition to Qt 5.4 that provides a web rendering engine based on Chromium.

A Debian Qt maintainer wrote to the KDE developers this week over the problems posed by needing to package QtWebEngine. "It's quite a very hard piece of software to package."

QtWebEngine embeds a lot of third-party code/libraries that Debian and others would prefer to link against their system versions than bundle the libraries, debugging symbols can't be built on most architectures for QtWebEngine due to the high RAM + swap usage during the linking process (though some have brought up this would be bearable if they used the Gold linker), and oher difficulties in packaging this Qt module. While this message is sent from the Debian camp, reportedly it's much the same issues with Fedora as to why they don't package Chromium within their repository. Ubuntu will likely follow the position of Debian as well when it comes to the packaging of QtWebEngine.

Unfortunately, there's not a lot that appears to be happening to make it easier to package, but rather the initial feedback was that the distribution vendors should effectively learn to deal with the situation. One KDE developer had wrote, "[In my honest opinion it's] the duty of a distro is providing software to their users to use, if the rules of the distro make providing software hard/impossible they need to be updated or these distros need to understand they will lose users to more flexible distros."

Others had also chimed in that the distribution vendors should update their rules to deal with it, let Qt take responsibility for maintenance/fixes, etc.

There's been some suggestions that it shouldn't be a hard dependency on QtWebEngine so packagers could swap it out for an alternative web rendering engine or perhaps there should be a new, self-contained, lightweight layout engine -- frequently being mentioned is why do email clients need a full-blown web engine. However, it's unlikely that either change would happen in the immediate future. Some also don't like QtWebEngine for being based on Chromium that in turn comes from the "evil" Google, it's too tied to FFmpeg, the V8 JavaScript JIT engine causes problems for some architectures, etc.

The start of the mailing list discussion about the QtWebEngine packaging issues can be found here; it's a lot of bickering on both sides with polarized views on the matter.