net-im/telegram-desktop requires this library built with qt6 instead of qt5, to properly transition into the qt6 world, a change which is starting to get pressing now it's been 5 months since upstream dropped support for qt5 linux builds. What this library is required for isn't very interesting[1][2], as it's just using some helpers to deal with URLs and portals, and while there is a shim header available in the tree (for windows and mac) we can use to get this going, upstream might start using more of this and it's a good idea to preserve the full functionality if possible. I'm not sure how this is best done. It doesn't feel OK to pull in the entirety of Qt5 for this library when the application is built for Qt6, even if it somehow works to link the application like this. A different approach would be to bundle this library as part of the net-im/telegram-desktop ebuild, which feels like a slippery slope when tdesktop starts depending on more kde libraries or other qt6 programs decide to use these as well. The final approach would be to either have a SLOT for a qt6 build, or an EXPAND_USE for a multi-build (like multilib), that installs the qt6 library in either a different directory or under a different name. I'm open to other suggestions on how to solve this as well. [1]: https://github.com/telegramdesktop/tdesktop/blob/e20840b4d4c828d930b55a93995ded9eb2784c2d/Telegram/SourceFiles/core/utils.h#L38 [2]: https://github.com/telegramdesktop/tdesktop/blob/8bd0ff7925d8befaab4b339959a0d2dec855b04a/Telegram/SourceFiles/window/main_window.cpp#L1004 Related links: https://github.com/gentoo/gentoo/pull/27300 https://github.com/telegramdesktop/tdesktop/issues/25073
There is no Qt6 based release of Frameworks yet, not even scheduled. There will not be flags for optional support because it would be a total mess.
The current version of the library already has the option to be built with Qt6, and it works fine, though I understand wanting to stick to officially supported releases. But this means I'll have to bundle it. I'd rather not do this but if there's no other choice... As of late more and more programs are being released using bleeding edge versions of various libraries and it's getting increasingly harder to package them, I hope this isn't a trend that will grow too much...
(In reply to Esteve Varela Colominas from comment #2) > As of late more and more programs are being released using bleeding edge > versions of various libraries and it's getting increasingly harder to > package them, I hope this isn't a trend that will grow too much... That's their choice for building against moving targets, not ours.
(In reply to Andreas Sturmlechner from comment #3) > That's their choice for building against moving targets, not ours. Unfortunately it ends up being a problem when packaging. But sorry, this isn't the place to moan about this right now. Thanks for responding, I'll keep the issue open as part of the tracker for qt6 support in telegram, should the situation change in the future.
Some upstreams are worse than others.
net-im/telegram-desktop no longer requires this as of 4.2.3. They chose to bundle upstream: https://github.com/telegramdesktop/tdesktop/commit/2a6e2fa353d5c4b7ab6a05eef5ce8952c78c2a73
(In reply to Joe Kappus from comment #6) > net-im/telegram-desktop no longer requires this as of 4.2.3. They chose to > bundle upstream: Right decision to bundle in this case since they have to do their own bugfixing without upstream release support. Resolving as obsolete. When kcoreaddons will become available in Gentoo then as part of a KF6 (Tier 1 or full) release.
