=dev-libs/kdiagram-2.8.0 fails its test phase when some dev-qt/* libraries have different versions from each other. On the system where I observed this (in which my initial setup work was interrupted for several weeks, so when I returned to it I resynced the Portage tree and resumed my aborted initial from-nearly-nothing @world update), for example, dev-qt/{linguist-tools,qtconcurrent,qtcore,qtdbus,qtnetwork,qtsql,qttest,qttranslations,qtwaylandscanner,qtxml} are all on 5.15.10 or some revision thereof, while dev-qt/{qtdeclarative,qtgui,qtprintsupport,qtsvg,qtwebchannel,qtwebengine,qtwidgets} are all on some version resembling 5.15.8. In the LastTest.log file the output from the first failed test, "KGanttMultiItems", is the single line "Cannot mix incompatible Qt library (5.15.8) with this library (5.15.10)"; the other failed tests have the same.
Created attachment 870897 [details] dev-libs:kdiagram-2.8.0:20230918-171845.log.gz
Created attachment 870898 [details] LastTest.log
Created attachment 870899 [details] emerge-info.txt
Unfortunately there is nothing a single leaf package can do in such circumstances.
Unless we would be doing something like this, which I have been pondering before: https://github.com/gentoo/qt/compare/master...a17r:qt:qtenforcement ...with possibly dire consequences for people's Portage upgrade output.
(In reply to Andreas Sturmlechner from comment #5) > Unless we would be doing something like this, which I have been pondering > before: > > https://github.com/gentoo/qt/compare/master...a17r:qt:qtenforcement > > ...with possibly dire consequences for people's Portage upgrade output. Please don't.
Could subslot dependencies help? I suppose perhaps not, since USE=test controls DEPEND where IIUC subslot dependencies are defined to be no-ops, but if the kdiagram rebuild were triggered by a change in its dependencies rather than just the version bump, presumably the package manager would schedule it after the last of those dependencies ...
(In reply to Sam James from comment #6) > (In reply to Andreas Sturmlechner from comment #5) > > Unless we would be doing something like this, which I have been pondering > > before: > > > > https://github.com/gentoo/qt/compare/master...a17r:qt:qtenforcement > > > > ...with possibly dire consequences for people's Portage upgrade output. > > Please don't. ...and with that, this is closed. :)