> Does it mean that the binaries we distribute should work on that? I have been maintaining XCB plugin and the bundled xkbcommon and xcb 3rd party sources based on the assumption that an answer to this question is - yes.
________________________________ From: Development <[email protected]> on behalf of Tony Sarajärvi <[email protected]> Sent: Thursday, May 2, 2019 1:48 PM To: [email protected] Subject: [Development] A monologue about platforms in the Qt world 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 [email protected] +358 50 482 1416 http://qt.io _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
