-
-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transition formulae to Qt 5 #1705
Comments
From prior Slack discussions: * automoc4 - No release since 2009, no Qt5 support.
* avidemux - New releases have Qt5 support, OS X dmg ships with by default.
* codequery - Has Qt5 support since 0.16.0.
* coin - Only optional but no Qt5 support, no release since 2012.
* cuty_capt - No release since 2011, no Qt5 support.
* djview4 - Should go and live in Homebrew/gui. Has Qt5 support.
* ezlupdate - No Qt5 support.
* gammaray - Has Qt5 support, should be the default.
* gnuplot - Has Qt5 support, is recommended by upstream over Qt4.
* gnuradio - Optional in formula, but no Qt5 support.
* gpsbabel - Has Qt5 support, is preferred in upstream configure script.
* gwenhywfar - No Qt5 support, even in latest 2016 beta.
* kdiff3 - Has Qt5 support, but Qt4 is default in upstream dmg.
* libdbusmenu-qt - Has Qt5 support in upstream, but no new release in 4 years.
* libechonest - Has Qt5 support, but using it renames headers which is quite breaky. Upside: Would kill qjson dep.
* liblastfm - Has Qt5 support, preferred by upstream.
* libqglviewer - Has Qt5 support, we're two versions behind upstream currently.
* open-mesh - Is optional, no Qt5 support. Two versions behind upstream again.
* open-scene-graph - Is optional, support for Qt5 already in the formula.
* openal-soft - Is optional, no Qt5 support.
* orfeo - We're 8 versions behind current, seriously. No Qt5 support still though! Qt4 can be disabled.
* poppler - Already has Qt5 support optional in the formula.
* pyqt - Lost cause. Already have PyQt5 for Qt5 support.
* pyqwt - No release since 2009, no Qt5 support.
* pyside - No Qt5 support.
* qca - Has optional Qt5 support but Qt4 is heavily preferred upstream.
* qcachegrind - Supports Qt5, has been recommending since last release in 2013.
* qjackctl - Supports Qt5, upstream has been default that since last release.
* qjson - Has Qt5 support, but libdbusmenu-qt needs this and doesn't support Qt5 in releases yet.
* quassel - One release behind upstream, has announced Qt4 support is being deprecated, switch to Qt5.
* quazip - Has Qt5 support.
* qwt - Has Qt5 support but gnuradio/pyqwt/qwtpolar currently require it and would likely need migrating too.
* qwtpolar - One release behind upstream. Still no Qt5 support.
* qxmpp - Has Qt5 support.
* rcssserver - No release for 2+ years. No upstream commit for 2 years. No Qt5 support.
* shiboken - No Qt5 support.
* shrewsoft-vpn-client - No release for 2+ years, No Qt5 support.
* soccerwindow2 - No release in nearly 5 years, No Qt5 support.
* sqlitebrowser - Has Qt5 support. Upstream dmg uses Qt4 though.
* sqliteman - No Qt5 support. No release in 3+ years.
* suil - Qt is optional, already has Qt5 support in formula.
* ttfautohint - Has Qt5 support.
* valkyrie - No upstream release for 5+ years. No Qt5 support.
* visualnetkit - No upstream release in 7+ years. No Qt5 support. Already being patched for "new" Qt4 support, lol.
* wireshark - Optional but upstream moving towards Qt5 and away from Qt rapidly.
* zint - Optional, but no Qt5 support.
Potential for Qt5: 25/46
Could probably be migrated today: 15/46 |
@DomT4 OK, I've copied those notes up inline with the checkboxes. The only one that looks like it doesn't belong is wireshark since there's a qt5 option in the formula. |
@DomT4 Also, I don't see a qt5 option in suil. |
The list was drawn up a few months ago, it's not entirely up-to-date. Qt5 support was removed from that formula temporarily in 79b67fa. |
automoc4, cuty_capt, ezlupdate, gwenhywfar, pyqt, pyqwt, pyside, qwtpolar, rcssserver, shiboken, shrewsof, soccerwindow2, sqliteman, valkyrie, and visualnetkit all sound like boneyard candidates to me. |
@DomT4 Will there be a qt4 in versions? If so, since qt is only optional in coin, gnuradio, open-mesh, open-scene-graph, openal-soft, orfeo, suil, wireshark, zint, I guess they could have a 🎌 cross-tap dependency on homebrew/versions/qt4. |
Some of them are, but for example if you boneyard
You'd also have to boneyard The idea was to phase it out gradually, where for now we focus on switching the stuff that should be Qt5 but is Qt4 over to Qt5, and then go from there. It needs to be done fairly delicately for better or worse.
We're not planning to punt it out of the core. We're just expecting it to stop building completely and be too much pain to rescue for OS X 10.12 or 10.13. |
If as @UniqMartin said, "At this point it's EOL (since December 2015) and doesn't even receive security fixes," then I can't see justifying keeping it in core. But ho hum. |
We can always consider dropping the elements of Qt4 known to be particularly insecure at this point, but there's no getting around the fact that we can't just rip away support quickly and demand people cope with the Qt ecosystem being a slow, slow place. |
Ambiguous cases where someone has to actually decide something: |
Sounds like a good first step is to upgrade/boneyard the things that don't have reverse dependencies. |
For reference: http://blog.qt.io/blog/2015/05/26/qt-4-8-7-released/ That's where I took this information from and I haven't seen any updates to the information provided in that post, thus assume it's still valid. |
I've updated the above with rev-deps. Anything with a (*) has at least one. |
@ilovezfs Nice work. |
Pyqt4 can be built to use Qt5, and in my very limited experience, seems to be pretty much a drop-in upgrade. That might allow some things to stay out of the boneyard for a while anyway. |
We are working on PySide + Qt 5. No ETA yet. https://groups.google.com/forum/#!topic/pyside-dev/pqwzngAGLWE |
Wireshark is done: a059413 |
|
i got qt5 install fails in https://gist.github.com/anonymous/8a0db109e7f274dcd26f1fb5114102ac |
@ilovezfs: Can you update the list? |
@Eitot Done, thanks! |
|
@Homebrew/science and @Homebrew/games: FYI that this is getting pretty close to being done after which time we'll remove the Qt4 formula. I don't plan on personally updating those taps so it's probably worth thinking about what you want to do after we remove that formula. |
@Homebrew/science these are science formulae that use Qt 4 and don't have a Qt 5 option in the formula: alglib: required biopp: recommended amos: optional |
@Homebrew/games there are 3 formulae under the effect: |
Great work @tomyun. |
homebrew/science/paraview has been merged and now uses QT5. |
@Homebrew/science I have created a tracking issue for science: https://github.com/Homebrew/homebrew-science/issues/4595. |
|
|
🚢d. Amazing work everyone who helped here. |
Regarding rcssserver (together with monitor and logplayer): it is still alive and got a version bump earlier this year, still depending on Qt4 though. |
@godehardt You can create your own tap for that. There's no interest in having any Qt4 formulae in this tap, sorry. |
These depend on qt and don't already have a qt5 option.
(revdeps: libqalculate, homebrew/science/kat, homebrew/science/octave, tsung, homebrew/science/maxima, homebrew/science/unafold)
The text was updated successfully, but these errors were encountered: