See inline.
From: Development <[email protected]<mailto:[email protected]>> on behalf of Danila Malyutin <[email protected]<mailto:[email protected]>> Sent: Friday, May 3, 2019 4:07 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Development] A monologue about platforms in the Qt world > 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 <[email protected]<mailto:[email protected]>>: 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. There are two perspectives to this: the Qt Project perspective, the The Qt Company perspective. As the company, "support" is a service we sell. People can ask for help, and we need to document on which platforms we help them with problems. That includes development hosts, and deployment targets. For the Qt Project, what matters is which platforms we want our code to compile on, and for which platforms we want to provide pre-built binaries. Ideally these two lists are mostly the same, but it's conceptually quite ok for TQtC to provide some platform support as a support or consulting service that includes developing patches. Might not be the most scalable business model under the sun, but whatever. I perhaps recall this wrongly, but I think that's what we used to call "Tier 1" vs "Tier 2" supported platforms. Tier 1 platforms: we provide tested binaries, verified through CI and pre-release package testing. You can expect a top out-of-the-installer experience. Tier 2: things are supposed to work, but they might not, and if they don't we'll help you with fixing it. This split still makes sense to me. The Qt Project at large should primarily care about Tier 1, ie contributors write code with those in mind (while being aware that there are also Tier 2 platforms); if changes break a tier 2, then it becomes TQtC’s problem to fix. 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. Why don’t we make the exact way of turning a clean Linux distro-install into a "Qt reference configuration" available to everyone else? The way build machines are provisioned in Coin is rather opaque, even with some of the respective provisioning scripts available in the qt5.git repo [1]. Having to document on a (notoriously outdated) wiki how to set up things to build Qt from source, when we have that knowledge literally codified somewhere for Coin, doesn’t seem effective. 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 If we promise that 5.12 is supported for three years on a list of platforms, then we either need to be able to keep that promise, or document before-hand that support for certain platforms will expire during the lifetime of 5.12. We can perhaps downgrade them from tier 1 to tier 2 (if that’s a thing), so that we can kick things out of Coin (if only because it becomes a security liability to run an unsupported OS). Cheers, Volker [1] https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
