#49721: dangerous bug in Qt5 --------------------------+------------------------ Reporter: rjvbertin@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt5 | --------------------------+------------------------ Comment (by rjvbertin@…): Replying to [comment:12 mcalhoun@…]:
I am a full supporter of cutting edge experimentation but only in some sort of -devel port.[[BR]] Personally, I use Qt for my work and need at least one non-experimental version around.
Well, that's just one more argument to have a qt5-kde port, and for the approach I'm taking with the patch in question. If you read my earlier explanation, it doesn't change anything if you don't activate the new code-paths it provides. That is also a prerequisite for getting it accepted upstream, because Apple won't accept applications using XDG- compliant locations in their App Store. Since you mention it: does it matter for your work whether Qt applications use ~/Library/Preferences and ~/Library/Application Support or rather ~/.config and ~/.local/share ? It's the possibility to support both options that makes my patch so complicated (and hard to defend without being able to refer to real-world use cases).
Perhaps this is the point of confusion.[[BR]] When I say merged, I mean merged into the git repository that Qt uses for development.[[BR]] I do not mean released.[[BR]]
Oh, I know that. The point remains that Qt's vetting process is one I only engage in if I'm more or less certain that my proposition will be accepted. And when that proposition isn't changing or intersecting with something else I'm working on, because their "gerrit" is *really* annoying in that case.
If you look at certain changes ([https://codereview.qt- project.org/#/c/140876/ 140876], [https://codereview.qt-project.org/#/c/125968/ 125968], [https://codereview.qt-project.org/#/c/127759/ 127759] to name just a few), they have been merged but not released.[[BR]] In fact, it may be quite some time (months) before they are released, but since they have been vetted and approved by upstream developers, they are excellent candidates for patchfiles.[[BR]] For those types of changes, there is indeed great use in incorporating them into MacPorts.[[BR]] In fact, Qt will not fully build on El Capitan without at least [https://codereview.qt-project.org/#/c/127759/ one of them].
-- Ticket URL: <https://trac.macports.org/ticket/49721#comment:13> MacPorts <https://www.macports.org/> Ports system for OS X