Policy regarding QtWebKit and QtScript

[Vadim Zhukov]

2015-12-25 15:01 GMT+03:00 Adriaan de Groot <groot at kde.org>:
> On Friday 25 December 2015 12:42:26 you wrote:
>> On Donnerstag, 24. Dezember 2015 12:14:06 CET Adriaan de Groot wrote:
>> > On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer
>> >
>> > wrote:
>> > > > The idea that users may have remainders of QtWebKit 5.5 on their disk
>> > > > (or
>> > > > not and thus unresolvable linkage) and install Qt 5.6 and still have
>> > > > (not
>> > > > recompiled) client code that is now gonna crash scares me a bit - it
>> > > > doesn't really improve reputation. Distros will virtually *have* to
>> > > > provide
>> > > > downstream webkit solutions to cover 3rd party installs and we'll get
>> > > > "somthing broke" reports on this all over the place.
>> > >
>> > > What we distro packagers are going to do is to recompile QtWebkit for as
>> > > long  ans possible/necessary.
>> >
>> > If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what
>> > the new thing is called) is an absolute terror to get building in FreeBSD.
>> > There are apparently source-compatibility issues and it takes a great big
>> > stonkin' machine to compile it at all.
>>
>> Sorry, but how is "it takes long to compile" and argument for or against a
>> piece of software if there is no feature equivalent alternative that takes
>> less time to compile?
>
> Please don't focus on *one* single part of what I explicitly indicated was at-
> that-time-hearsay. Since then I've actually tried to compile Qt 5.6 beta.
>
>> Qt WebEngine is far easier to compile than Qt WebKit in my experience, and
>> it certainly doesn't take significantly longer. And of course the former is
>> far superior than the latter.
>
> This bit makes it harder:
>
> ./tools/qmake/mkspecs/features/functions.prf:    skipBuild("Qt WebEngine can
> currently only be built for Linux (GCC/clang), Windows (MSVC 2013 or 2015), OS
> X (10.9/XCode 5.1+) or Qt for Device Creation.")
>
> So from the FreeBSD packagers' side, it *is* a big deal, because they not only
> have to get KDE software to work (which has traditionally been very cross-
> platform, and is easy to work with), and Qt to work (which has traditionally
> been very cross-platform, and is generally easy to work with), but also deal
> with 975MB of Chromium. That is, as they say, quite a lump of coal in the
> stocking.

At first, I should note that I don't have anything against idea of
having modern web engine in Qt and/or KDE apps. And I really like Qt
and KDE design in general, especially nowadays. But Chromium, and thus
QtWebEngine is not portable, really. I don't have any win-win solution
here, sorry. That's just a description of what I see from my point of
view of OpenBSD porter.

Same applies to OpenBSD. QtWebEngine uses its own, qmake-based, build
system, so at least 50% of effort of porting Chromium should be
repeated.

Next thing is that chromium already requires some tricks to allow it
being compiled (or, more technically, linked) on 32-bit platforms. In
fact, on OpenBSD it currently packages on i386 and amd64; it's going
to became amd64 soon:
http://betanews.com/2015/11/30/google-killing-chrome-for-32-bit-linux/
. QtWebkit is large enough, too, but still fits into 32-bit address
space. That's not about trashing swap partition; that's about being
able to link stuff at all.

KDE4 runs on OpenBSD/sparc64 (I had successful reports from users).
Chromium doesn't work there due to (at least) memory alignment bugs.
QtWebEngine is out of SPARC game, therefore, too. Adoption of
QtWebEngine will mean no modern KDE for sparc64. And it's a 64-bit
platform, not limited by 2/3/4GB of address space! I'm not ever
talking about MIPS world...

And, as it was already mentioned many times, Chromium/QtWebEngine
bundles a lot of software, often outdated. What happens when a
security flaw is found in, say, giflib? - The packager adds an
upstream patch or rolls a new release from upstream. What happens in
case of bundled copy? - Nothing, because chromium developers don't
want to break things and thus do not care about updating software
ASAP. And if they do, those updates are delayed because the
chromium/Qt packages need to be redone (reviewed, rebuilt, repackaged
and verified). And that's far less trivial and takes far more time
than patching and repackaging giflib. End users get unsecure software
as a result, possible even thinking: "I'm secure now, since I've just
updated giflib package". Who'll stand up and say: "I want to make
users of my software feel safe while my software is actually unsafe"?
- Noone will, right? But it happens.

There is a little chance QtWebEngine will be ported on OpenBSD: if
someone will come in and fix Chromium and QtWebEngine to bundle less,
at least. I won't volunteer: handling a few hundreds of KDE ports +
ports of Qt itself is already big enough task for me.

So, again, it was my seeing, both for today and tomorrow. Now I'm back
to porting other KDE5 stuff. Thank you for reading!

--
  WBR,
  Vadim Zhukov