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