[Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Thiago Macieira]

On Tuesday, 12 January 2021 02:46:23 PST Giuseppe D'Angelo via Development 
wrote:
> So why do we even ship 3rd parties with Qt in the current form if we
> can't be bother to update them promptly (for bug fixes, security fixes,
> and the like)? Wouldn't it be better to just provide a script (cmake's
> external project, recipe, conan build file, vcpkg, choco, WHATEVER) so
> that the user can download the latest version of 3rd parties
> automatically? Or just NOT provide them and push the problem onto the user?

Convenience and history.

There are two levels of convenience too: building from source and binary 
distribution. The former is a historical artefact that we should eventually 
get rid of (see Kai's reply). When we had a poor configure script, it was too 
difficult to find third-party dependencies, so we ended up adding everything 
to Qt itself. That made it easier to build out of the box. To be frank, it 
still does when I need to build 32-bit, since my distro of choice for 
development (Clear Linux) has no useful 32-bit support and I don't care to 
install all the baggage for something I do once every 2 years (last two times 
I built 32-bit: 2018-07-12, 2020-12-11).

The binary distribution issue is to reduce the number of DLLs one must 
distribute. That can be solved for most of the libraries by just building the 
dependencies as static, then compiling them into the Qt DLLs, but that doesn't 
remove the problem of forcing users to know they are there and then rebuild 
from source on need. I think we should to revisit this and ship all 
dependencies as shared libraries / DLLs, but I don't care enough about binary 
distribution to join the discussion. And besides, since it's not anonymously 
downloadable any more, I care even less.

After all of this, there will be a handful of third-parties that are 
integrated very deeply into Qt, like the cryptographic hashes, the FreeBSD 
strto(u)ll implementations and TinyCBOR, just to name QtCore dependencies. 
Because those are not "unbundleable", we have to apply security fixes 
ourselves. Fortunately, there haven't been any in any of them in years.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering