QT 6 vs. OpenSSL 3 migration?

[h-vetinari]

QT 6.x has been building on the feedstock for close to two month now. I presume it's going to be a pretty long and painful migration, so it sounds like we'll have to keep building for qt5 & qt6 in parallel once we start migrating - but I guess we have to start at some point...? At least the matplotlib stack should be ready for qt6 for a while already.

One particular reason for opening this issue for discussion is that qt depends on openssl, that other infinitely running migration (which I'd really like to settle before the EOL of openssl 1.1.1 in less than 10(!) months).

Not only that, but qt5 doesn't support openssl3 currently, and it's not sure when (if ever) that happens:

@h-vetinari: The post you quoted mentions:

Contacted support, they are working on porting changes from Qt6 to 5 and while it may not be officially supported, we will be able to compile the framework using openssl 3.x.

but there's no timeline; also, this bug was closed as out of scope, so I wouldn't expect this to work soon.

That leads to an unfortunate coupling between these two long-running migrations, hence this issue to discuss how to deal with it. There are 4 possible builds we might do (for feedstocks that depend on both qt and openssl):

openssl ver.	qt ver.	required	comment
1.1.1	5.x	✅	old world
1.1.1	6.x		possible
3.x	5.x		currently not supported by qt; reason the migrations are coupled
3.x	6.x	✅	new world; works

From a CI matrix standpoint, it would be nice to only build the old & the new world, but this will put the solver in a world of pain (amplifying the current OpenSSL issues), because if any package then requires openssl 1.1.1 or qt5, it'd have to effectively replace the whole environment.

I'm thinking we could zip as follows

openssl:
  - 1.1.1
  - 1.1.1
  - 3.0
qt:
  - 5
  - 6
  - 6

I don't think this would blow up the CI too much since probably not many packages are host-depending on both openssl and qt.

Of course, if ever we get openssl 3 builds for qt5, then the discussion becomes moot and we can remove the zip and just build qt5 & qt6 for openssl 3.

CC @conda-forge/qt-main @conda-forge/openssl @conda-forge/core

[pkgw]

Thank you very much for all of your work on these issues, @h-vetinari!

From a little light digging, it seems like various distributions are building the Qt5/OpenSSL3 combo — here's an Ubuntu patch (via this patches-applied source tree; see also followup patch) and this Macports issue suggests that they build it too. Are we not comfortable or able to take the same route? I wouldn't love applying patches from internet randos, but if Ubuntu has a patchset, I'd presume that we'd be OK with using it. Is there a reason we can't?

(Perhaps any detailed discussion of this topic should go on conda-forge/qt-main-feedstock#63, but the broad rationale seems relevant to this issue.)

(Also, upon digging into the MacPorts build files, I don't think I see any OpenSSL-related patches or commits, so I'm not sure what's going on there.)

[h-vetinari]

Are we not comfortable or able to take the same route? I wouldn't love applying patches from internet randos, but if Ubuntu has a patchset, I'd presume that we'd be OK with using it. Is there a reason we can't?

Thanks for digging this up @pkgw (and for your help debugging the cryptography issues; we'd still be stuck on that otherwise...)!

I see no reason not to use the ubuntu patches (but then, I'm not a maintainer on the qt feedstock).

That would mercifully uncouple the two migrations, but then we'd still have to decide when/how we add a migration for qt6... :)

[jakirkham]

If we can decouple the migrators, that would be great. If not, one migrator can depend on another using wait_for_migrators ( regro/cf-scripts#1405 )

[h-vetinari]

If we can decouple the migrators, that would be great. If not, one migrator can depend on another using wait_for_migrators

That's a good point - I know wait_for_migrators, but I don't know if it's possible to zip: into another existing migrator (as we'd have to do avoid the qt5 + openssl 3 combination; the ordering of the migrations is pretty self-evident, as the openssl migrator has been running for over a year + qt depends on openssl).

But since it looks like we should be able to avoid that entirely by patching qt5, the rest becomes much easier (and less time-sensitive to the EOL of OpenSSL 1.1.1).

[pkgw]

The updated PR conda-forge/qt-main-feedstock#72 by @h-vetinari that adds OpenSSL 3 builds to Qt5 was just merged by @hmaarrfk, so it looks like we will be able to dodge the issue of coupling the migrations here!

[pkgw]

Also, here's an issue with some more in-depth technical discussion about Qt6 migration mechanics:

conda-forge/qt-main-feedstock#49

[jakirkham]

Glad to hear we have a path forward 🎉 Thanks for working on that Axel! 🙏

During the conda-forge meeting someone asked, do we have to do something special for Qt on aarch64/ppc64le?

[Tobias-Fischer]

For qt-main v5, we have to manually (locally) build aarch64, and we don't build ppc64le.
For qt-main v6, we don't build ppc64le.
qt-webengine is baaad .. we don't have v6 yet, and v5 is a mess with lots of manual builds (basically all platforms)

[h-vetinari]

During the conda-forge meeting someone asked, do we have to do something special for Qt on aarch64/ppc64le?

New to qt6 is the ability to cross-compile, so ppc could presumably be done for qt6 (see here). AFAIU ppc is not supported upstream (making this very hard for qt5).

[h-vetinari]

qt-webengine is baaad .. we don't have v6 yet, and v5 is a mess with lots of manual builds (basically all platforms)

Apparently it's also out of sync with qt5-main in terms of migrations 🥲

[h-vetinari]

Also, here's an issue with some more in-depth technical discussion about Qt6 migration mechanics:

conda-forge/qt-main-feedstock#49

OK, let's just that issue to discuss the migration (but first, realistically, finish the one for qt 5.15...).

This issue was mainly about the coupling with OpenSSL, and we managed to solve that, so closing.