Summary: | dev-qt/qtgui-5.14.1 ignores accessibility use flag (PATCH) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Nezic <dennisn> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | jstein |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 715774 | ||
Bug Blocks: |
Description
Dennis Nezic
2020-03-30 21:42:50 UTC
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 |