[Development] A monologue about platforms in the Qt world

Fri May 3 16:07:41 CEST 2019

> When selecting this operating system which we created packages with, we
tend to select a reasonable new one, most preferably a stable one, with a
good set of old libraries so that the backwards compatibility is good. Take
RHEL 7 for example. RHEL 7.0 was release in June 2014. In July 2017 we got
the 7.4 update which we began using. RHEL 7.4 is still compatible with 7.0,
which means that our binaries are created with a new distro that creates
binaries compatible with distros created in 2014. At least sort of.

I found that to not be the case. For example, I couldn't get Qt Creator
4.8.0 (which was the first one using Qt 5.12) to run on RHEL/CentOS 7.3 due
to LIBDBUS_1_3 errors. Could be the same issue as with OpenSUSE though.

чт, 2 мая 2019 г. в 14:50, Tony Sarajärvi <tony.sarajarvi at qt.io>:

> Hi all!
>
> I'd like to open up a discussion about the platforms we "support".  This
> is like listening to a broken record, but once again it’s about adding or
> removing platforms in the CI, what’s supported and what we do packages
> with. But, this time I'm going to approach you a bit differently. Instead
> of simple questions, I'm going to bombard you with boring details. You need
> to know what exactly it is we are asking you about after all ;)
>
>
> What's a  supported platform?
> ---
> It means that The Qt Company gives you support if you stumble upon a
> problem with that distro and the Qt release promised to work on that. But
> what’s unclear is what it actually means that Qt should work on that
> platform. Does it mean that the binaries we distribute should work on that?
> Or does it mean that Qt builds on it if you take the sources and compile
> them yourself? This is one of the most asked questions we’ve had here. A
> good example is openSUSE 42.3 where examples don’t compile if you take our
> binary release and try to work with that. But if you would compile Qt on
> that distro, then it would work. (see
> https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the
> details). What do you think it means? Is one or the other answers wrong
> here?
>
>
> What a platform in the CI?
> ---
> Ok this one is pretty clear. A platform in the CI is a platform we see fit
> to be tested for a specific branch. The important thing here is to realize
> that this is not the same thing as us supporting something. For obvious
> reasons it would be great if everything we supported was tested here, but
> because of the vast amount of combinations, we can't do that. We simply try
> to cover the most common cases here. And that's always up for debate! If
> you see that something is worth testing in the CI, create a ticket about it
> and justify why your configuration should be in there. This doesn't just
> mean adding platforms or compilers. It also means configurations like
> -no-gui or building examples for Android or something.
>
>
> What's a packaging configuration and why don't Linux binaries work as
> promised?
> ---
> Some configurations in the CI are used to actually create the binaries
> which we deliver as Qt binaries via the installer. They can be recognized
> by the "Packaging" keyword in the following files:
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qt5.txt
> For most platforms this makes a lot of sense and they don't cause problems
> anywhere, but our Linux binaries are a different thing entirely. Where
> Windows and macOS binaries work here and there, Linux distros tend to be
> more strict to what works and where. The library dependencies make things
> not work backwards as well as on Windows and macOS. Which brings us to the
> problem mentioned earlier at supported platforms. Binaries created with
> RHEL 7.4 don't tend to work on openSUSE 42.3, but they do compile.
>
> When selecting this operating system which we created packages with, we
> tend to select a reasonable new one, most preferably a stable one, with a
> good set of old libraries so that the backwards compatibility is good. Take
> RHEL 7 for example. RHEL 7.0 was release in June 2014. In July 2017 we got
> the 7.4 update which we began using. RHEL 7.4 is still compatible with 7.0,
> which means that our binaries are created with a new distro that creates
> binaries compatible with distros created in 2014. At least sort of.
>
> But the distro we use, isn't always the out-of-the-box distro. When we
> used RHEL 6.6 for example, we replaced the bluez (for Bluetooth) libraries
> with own ones so that Qt binaries would have the features enabled that were
> wished. That actually means that we didn't use RHEL 6.6 to create the
> releases, but in fact a custom distro based on RHEL 6.6. (off on a tangent
> here: Qt 5.6 sources actually don't even compile on an out-of-the-box RHEL
> 6.6 because we now missed that during verification (bug created!). And
> actually by us installing devtoolsets provided by RHEL, us installing
> custom Pythons, extracting own libclangs, perhaps build our own openssl
> from sources, one could actually argue, that we don't use RHEL 7.4 either,
> but our own custom Linux based on RHEL 7.4.
>
>
> Lifespan of distros
> ---
> This is something we should have thought more about, but didn't. Perhaps
> still don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was
> released on the 6th Dec 2018. It has a promised lifespan to at least the
> end of 2021. With us actually going development and testing before the
> actual release, we need to have the environment which we work on working at
> least 6 months before we release. Now that RHEL 7.4 was such an environment
> which was available then. Already released July 2017 and having an EOL (end
> of life) August 2019. Perfect! But the problem is our Qt 5.12.2, .3, .4, .5
> releases. Should we be doing releases with a distro that isn't even
> supported by RedHat themselves? And there's the big question #1!
>
> Because of ignorance we didn't think about this when we documented things.
> We just blindly say that Qt 5.12 supports RHEL 7.4, because that's what we
> have in the CI! Yeah, but are we really supporting it in 2021, when RedHat
> themselves have pulled the plug on it over 2 years before that? Could we
> just update to the latest RHEL after all? Especially since we didn't use
> RHEL 7.4 to begin with, but our own distro as we modified the original RHEL?
> Tony Sarajärvi
> CI Tech Lead
>
> The Qt Company
> Elektroniikkatie 13
> 90590, Oulu, Finland
> tony.sarajarvi at qt.io
> +358 50 482 1416
> http://qt.io
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190503/f53b0521/attachment.html>