Qt5 expected longeivity poll

[dmpogo]

What would be your guess ?

[kimchi_sg]

gtk2 main holdout still using it is GIMP, there is no major software similarly holding on to qt5 so the purge should be much faster.

[Ralphred]

[Ionen]

Qt5 is much more of a mess to keep around than gtk2 is, and upstream support been garbage for non-commercial users. The only reason it's afloat is because KDE community been doing the support for Qt5 instead with large patchsets and backports from Qt6, but now that they're moving on to Qt6... Not to mention that our own Gentoo maintainers are moving on as well and do not necessarily have time or the will to keep working on Qt5.

Really hard to give an estimate when it'll go away from the tree like Qt4 before it though, will depend on state of the migration of packages and how much trouble Qt5 is causing. If we reach a point where the only packages left using Qt5 have dead upstreams and little hope to ever be ported to Qt6, last-riting these stragglers and then Qt5 could happen. Currently we're merely recommending that packages drop their optional Qt5 support and force Qt6 where possible so can "start" working toward it, and reduce pulling Qt5 on users' systems for nothing.

Some modules may go away earlier than the rest, e.g. qtwebengine:5 hopefully (but still plenty of blockers even just for that one).

[dmpogo]

[dmpogo]

For me the main concern with Qt5 is a bunch of small programs, for which GUI is a side project, written once for QT5, but unclear when and if will be updated. For instance, wpa_supplicant wpa_gui part, which I got used to and rely on. I don't see any discussion of transition to Qt6 on their mailing lists. Or GUI part of avahi. Or even VLC, although they will probably move eventually. Also kdesvn has little chance it seem - and yes, I use it a regularly And kdesvn keeps a bunch of framework-5 packages that would have been gone.

[Ionen]

On the bright side, porting to Qt6 is relatively easy, esp. when using dev-qt/qt5compat (some core removed functions are still usable with it, allowing to keep most of the code as-is, may be more of an issue when Qt7 comes around), or at least assuming simple applications -- someone can potentially do it even with minimal C++ and Qt knowledge. So if someone cares at all I imagine many of these will be migrated in time, by users w/ PRs if need be if upstreams do not do it themselves.

As for VLC... it's already ported to Qt6, albeit the time it's taking for vlc4 with qt6 to release been becoming a bit joke-tier like gimp3 with gtk3 (gimp3 will most likely release first though). Meanwhile vlc3 been accumulating issues that are far worse/urgent than the fact it's still on qt5 -- not that you can be worried about it getting last-rited in any foreseeable future, would need to be exceptionally broken with no hope of vlc4 continuing.

Edit: Not familiar with kdesvn, but at a glance upstream I'm not too hopeful either. Seems to have hardly any activity upstream excluding translations and it's been accumulating a wall of patches downstream, but who knows. Packages depending on qt5 kde-frameworks will likely get last-rited earlier than packages depending on just qt5 as it's a huge stack to keep though.

[dmpogo]

[sdauth]

I still have a lot of apps which depends on qt5, while I can find some alternative for some or tweak some use flag to get rid of it, at the end of the day, I will still have to build it for heavily used application like keepassxc, makemkv...
I think 3 years is a good bet.. Hopefully less..

[dmpogo]

at least wireshark you can recompile for qt6. It can support either.

What I did, is created use_noqt5 file in /etc/portage/package.use/ and slowly add there packages that can use qt5 but do not have to anymore, such as wireshark, libreoffice with -qt5

[asturm]