Tiny little fix. The current ebuild (up to 5.14.1) doesn't respect the "accessibility" USE flag ... ie. it gets compiled regardless, even if I disable the USE flag. --- /dev/shm/share/fuck 2020-03-30 17:29:32.372534826 -0400 +++ ./qtgui-5.14.1-r3.ebuild 2020-03-30 17:29:16.000000000 -0400 @@ -165,6 +165,7 @@ src_configure() { local myconf=( $(usex dbus -dbus-linked '') + $(qt_use accessibility) $(qt_use egl) $(qt_use eglfs) $(usex eglfs '-gbm -kms' '') Reproducible: Always
NACK. Upstream strongly recommends keeping accessibility enabled. We used to allow disabling it in Qt4 and it caused countless problems. I don't want to support this configuration in gentoo. See also https://github.com/gentoo/gentoo/blob/master/eclass/qt5-build.eclass#L541-L543
Should we drop the flag then completely?
Current use-revdeps are media-sound/picard, media-sound/teamspeak-client.
The flag is there to make sure that if you want a functional accessibility support, the right dependencies are pulled in for the atspi bridge, which requires dbus. TBH the flag is somewhat historical, because in the early Qt5 days atspi-bridge required additional external deps which I didn't want to force on everyone. Those additional deps have since been dropped by upstream, but you still need to build Qt with dbus support (and the xcb platform backend). Do you have any better ideas on how to handle this?
(In reply to Davide Pesavento from comment #4) > Do you have any better ideas on how to handle this? Probably not, after all it is a global use flag so having it has some merit. I notice it still ticks > QT5_GENTOO_CONFIG=( > accessibility:accessibility-atspi-bridge > ) which does not appear to do any harm for a long time and even makes this build time effective.
Disabling it via qmake build flag definitely leads to numerous issues down the road in revdeps such as qtdeclarative, kdeclarative, PyQt5 and who knows what else, so it would require major testing work, that is just not worth the effort.
(In reply to Andreas Sturmlechner from comment #6) > Disabling it via qmake build flag definitely leads to numerous issues down > the road in revdeps such as qtdeclarative, kdeclarative, PyQt5 and who knows > what else, so it would require major testing work, that is just not worth > the effort. +1
