[Interest] [#ID:INC-1251018#] Installation issue.

Thiago Macieira thiago.macieira at intel.com
Tue Mar 12 17:12:02 CET 2019

On Tuesday, 12 March 2019 08:56:58 PDT Dr.-Ing. Christoph Cullmann wrote:
> > Advantage of this method is that we always get the latest, with latest
> > security fixes. If there are futher fixes that apply to users of Qt, then
> > all they need to do is rebuild. They will see clearly what those
> > libraries are. And it simplifies our own maintenance, of course.
> > 
> > But yes, a disadvantage is now having to deal with the buildsystem for
> > those libraries.
> As long as there is at least the idea to have some "helpers" to get external
> stuff build, that is fine.

The current idea is to use vcpkg to automate building from sources (yes, even 
on non-Windows). Whether we continue down that path will depend on how well 
it's working.

> > RHEL 7 was initially released in 2014. If you can't update to a 6-year-old
> > series in 2020 when upgrading a major Qt, you could have much bigger
> > problems.
> > 
> > I'd also advise looking into RHEL 8, which should be released this year,
> > for further long-term support.
> This will be no option, some of our larger customers will stay on 7 for
> the next X years. And yes, staying with some LTS Qt is no real solution,
> we had already in the past the issues that old Qt releases lacked critical
> bugfixes (critical for us, not necessarily for all people).

We'll have yet one more LTS Qt before 6.0: 5.15. I also expect that to be even 
longer term supported than the other ones. My point was only about 6.0 itself: 
when you do take that plunge, I recommend a full upgrade of everything else 

No, it won't be required. This is just what I recommend.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

More information about the Interest mailing list