I use FreeCAD and KDE Plasma. FreeCAD depends on pyside6 which in turn depends on a list of package in dev-qt/ The issue is that pyside6 isn't updated as often as dev-qt/* and I have to manually mask mask packages dev-qt/. My proposed solution is that packages that are a part of Qt for Python will be taken in by Gentoo Qt Project
Can't unless want to delay bumping Qt which I'd rather not over pyside (esp when things like Plasma 6 need these updates often early). Thing is that pyside6 doesn't release at same time as Qt (pyside6-6.7.0 is not released yet, and 6.6.3 is missing its release tarballs -- albeit it did get tagged). https://download.qt.io/official_releases/QtForPython/pyside6/
I understand that. Would delaying Qt stable be possible? Testing can keep its cadence.
(In reply to bor.belockopytov from comment #2) > I understand that. Would delaying Qt stable be possible? Testing can keep > its cadence. Plan is already to not stable 6.7.0 early (major changes), but patch releases will always have security fixes and delaying them is not so great (nothing in Qt itself this time around, but qtwebengine always has something). Pyside6's maintainer decided to start pinning to e.g. 6.6.2 rather than 6.6.* after something broke a while back though. Possible that it'd already work with 6.6.3 or at most with a minor patch.
That aside, there should be no need to mask though? At most portage should just be noisy with a WARNING: that it can't upgrade qt yet.
(In reply to Ionen Wolkens from comment #3) > Pyside6's maintainer decided to start pinning to e.g. 6.6.2 rather than > 6.6.* after something broke a while back though. Possible that it'd already > work with 6.6.3 or at most with a minor patch. (similar deal happens with PyQt6, typically can still e.g. use PyQt6-6.6.1 with 6.6.3 without any fixes, albeit it did break with 6.7.0 without a patch)
Unfortunately portage can't backtrack with pyside6 lagging behind. I currently have to have around --backtrack=100 for portage to be able to resolve. I don't think masking is reasonable just for pyside6.
> That aside, there should be no need to mask though? Not sure how that works, but I was able to upgrade a bunch of stuff after first knocking dev-qt/ category down to stable and then when stable got bumped masking 6.6.3
Can't really think of a (good) way to improve this situation other than doing the same that we do with PyQt6 -- which means not pinning (just a minimum version), and patching as needed so that it doesn't have to block updates. But this does mean added maintenance costs and unsure how much harder this is with PySide6 compared to PyQt6 and could understand not wanting to do this (or at least not on major bumps). Not something I particularly want to do myself as part of Qt bumps given (unlike PyQt6) I don't use pyside for anything, nor familiar with it at all, and don't particularly want to build/test it either. On a side-note, for anyone that would want to work on this, there is unkeyworded Qt rc before major bumps which could be used for pre-testing & patching/backporting fixes before releases even if done by non-Qt maintainers, 6.x.9999 ebuilds are "typically" in a good state too (don't recommend 6.9999 though). fwiw I fixed PyQt6 back in 2023-12-12 back when 6.7.0_beta1 released, not that it'd need to be that early.
Anyhow will assign to pyside6's maintainer in case want to rework the pinning model, feel free to close if prefer to keep things as is. Said my side of things for qt@'s end.
It's not possible to remove the pinning since pyside/shiboken is not at all forwards compatible. We had a more relaxed pinning before and this repeatadly broke pyside and/or shiboken. I do agree that it's super annoying though, I also use both KDE and Freecad so this hits me every qt upgrade as well. There is however nothing I can do. The only real fix is to convince upstream to release pyside simultaneously to the rest of qt.
pyside6 is being stabilized for the first time now (bug #930062), meaning that from now on it'll be possible to stabilize it together with Qt updates which should reduce problems in stable. Still not much I can do for ~testing users though. Will need to drop pyside6/shiboken6/pyside6-tools accept_keywords to allow for this to sync up.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b6c5cc5ba5241b71ad0f8d6bc14f50901be59aeb commit b6c5cc5ba5241b71ad0f8d6bc14f50901be59aeb Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-04-15 12:28:58 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-04-15 12:40:08 +0000 metadata/stabilization-groups/qt: add dev-python/pyside6 to qt6 Given bug #930062 is giving it its first stable and that these are pinning to exact Qt versions, qt@ will handle stabilizing these together with Qt upgrades from now on. Please inform qt@ if there's notable problems that should hold it back from stable (e.g. breaks stable freecad after USE=qt6 is un-stable.masked, in these cases may need to add freecad too). PyQt6 & friends technically need to be there when needed too, but in its case 6.6.1-r1 still works with 6.6.3 and its been patched to work with 6.7.0. So tend to be fine to stabilize out-of-sync. Bug: https://bugs.gentoo.org/930062 Bug: https://bugs.gentoo.org/928592 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> metadata/stabilization-groups/qt/qt6.group | 3 +++ 1 file changed, 3 insertions(+)
