[Development] Deprecating modules with 5.5

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Feb 6 19:45:05 CET 2015

On 2015-02-06 09:22, Robert Knight wrote:
>> It is just not practical to ship a second copy of dozens
>> of system libraries, all built as part of QtWebEngine. This is a nightmare
>> in terms of disk space, RAM use, potential for symbol conflicts and
>> delivery of security updates.
> These are all valid concerns but ultimately of secondary importance to most
> app developers
> who care most about delivering working software to their end users and for
> them the OS X / Windows
> model of bundling anything not guaranteed to be part of the base platform
> works quite nicely.
> We ship a complete copy of Qt in our non-open source app for Linux and a
> runtime wrapper that will
> choose on the fly whether to use it or not. Because of that we are able to
> offer a _better_ experience
> for our users than packaged open source software, which sucks.

...and you're keeping up to date with all the security patches to Qt,
Chromium, etc.? If not, your "better experience" is leaving your
application's users vulnerable.

Bad enough for individual applications to shoulder that burden. When you
talk about the cost of maintaining a web engine, don't forget that by
bundling Chromium, *you* (i.e. the Qt project) are taking on
responsibility for the security of that entire stack. This means
releasing a new version *of Qt* whenever a security issue is found in
Chromium. Or in anything that Chromium bundles.

Putting myself in the library/framework developer role, I would strongly
want to punt that burden to upstream / the distro.


More information about the Development mailing list