When an ebuild has a pin or a upper bound for Qt (e.g. =qtbase-6.7.3* often seen in pyside6 ebuilds, or <qtbase-6.8 in pyqt6), and that there is a pending update for newer Qt stack without a visible matching ebuild that lifts the bounds, the behaviour I'd expect is to see the usual "WARNING: updates were skipped, don't worry about it" and let users update other things -- but it instead leave users unable to update by presenting them with complex dependency conflicts (unless they --exclude "dev-qt/*", or mask the newer Qt for now). Have not tested a simpler case but I suspect it's due to "skip chains" not being considered, aka like: 1. package Other-0, and grouped packages A-1.0 + B-1.0 are installed 2. Other-0 depends on <A-2.0 and does not care for version of B 3. A-2.0 and B-2.0 updates are pending 4. being a same-version group, B-2.0 depends on =A-2.0 Then update for A is skipped, which prevents updating B resulting in a conflict rather than B being skipped as well. Haven't replicated the conflict myself to provide an output, but for recent examples into issues with these Qt versions: https://forums.gentoo.org/viewtopic-t-1171997.html https://forums.gentoo.org/viewtopic-t-1172085.html (that one was self-inflicted, but it's the same thing) There should also be a few bugs that were likely closed as INVALID or resolved by a pyside6 bump (plus more in the past for Qt5 I'd imagine) but have not searched.
