What it says on the tin. I don't expect a qt6 program to rely on a singular qt5 library, so this feels like a typo, unless I'm missing something?
Yeah, that doesn't look intentional: qt6? ( dev-qt/qtbase:6[gui,widgets] ) !qt6? ( dev-qt/qtprintsupport:5[cups] ) dev-qt/qtprintsupport:5[cups] <- duplicate On a side-clarification for anyone that don't know, [gui,widgets] that the first dependency does enables qtprintsupport on qtbase (which is fine), while qtbase[cups] is typically not necessary unless this does something special.
Also, may want to consider just dropping qt5 entirely if want to simply the ebuild. Posted on gentoo-dev some time ago that it's time to do away with optional qt5 support.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10290aa19fe42fb2289984941a129fc689de1ff5 commit 10290aa19fe42fb2289984941a129fc689de1ff5 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-04-21 07:57:39 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-04-21 08:03:54 +0000 app-text/xpdf: Drop IUSE qt6 (Qt5 build option) The question remains why we added back an old PDF toolkit with plenty of known security holes fixed by poppler since forking XPDF-3. Yeah right, "fixed in xpdf-5" which has not become a thing since 2022. But at the very least it must not block Qt5 cleanup. Held my nose and just dropped that. Bug: https://bugs.gentoo.org/856475 Closes: https://bugs.gentoo.org/939729 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../xpdf/{xpdf-4.05.ebuild => xpdf-4.05-r1.ebuild} | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-)
