Hi Stuart, On Tue, Nov 26, 2024 at 12:07:56AM +1100, Stuart Prescott wrote: > > Hi Julian > > The transition is indeed potentially messy. > > With modularised Qt packaging, I think the desired end state will be > applications packages having dependencies only on a qtpy package that has > the Python modules and no Qt dependencies. Individual packages should then > select the correct Qt6/PySide6 packages that are needed. > > The metapackages are useful for users who just want the batteries included > installation, for some packages where upstream is not clear about which > parts of Qt6 are needed, or where they need so much they may as well have > all of it. > > A few of python3-qtpy's existing rdeps already specify the packages they > need; some of them even specify qt6 packages meaning that our current > packaging ends up installing both Qt5 and Qt6 for those users. Incidentally, > I couldn't find any existing users that wanted qtpy and pyside2 which is why > I didn't add that metapackage. > > > (1) Upload the new qtpy, and then file serious bugs against all of > > these packages, requiring them to update their dependencies > > immediately. > > I'm never a fan of "break the world" approaches - 34 (binary) packages > needing work isn't insurmountable but it's quite a lot.
Indeed! > > (2) Change python3-qtpy to depend on python3-qtpy-qt5 for the time > > being, and file important bugs against the depending packages, asking > > them to switch to one of the python3-qtpy-* packages, and giving a > > timeline for dropping the -qt5 dependency (presumably early in the > > next release cycle). > > As you note, with the current structure, that would actually mean that a > pyside6 package slurped in qt5 as well. That doesn't feel like a good state > for us to go through. We still end up with a big flag day and breakage some > time in the future. Yes :/ > > (3) File important bugs against the depending packages, asking them to > > change their dependencies to something like > > > > python3-qtpy-qt5 | python3-qtpy (<< 2.4.1-3) > > > > (where -qt5 can obviously be replaced with one of the other > > metapackages), with a deadline, and after that time, doing NMUs where > > needed and then updating the python3-qtpy package to 2.4.1-3 with > > these changes. > > I can see that dragging on for longer than we all have patience for :) and > it still has the flag day problem. But this is where NMUs come in: we tag the bugs with a usertag so they're easy to track, and say in the initial bug report that if the packages are not updated within 30 days, we will do an NMU to make this change. That way, it doesn't drag on (this bug has been open for ages, so an extra month is not a problem if we file the bugs within the next week; the NMUs can then be completed by first week of January). > Another alternative would be > > 4) > Move the python module to an additional package, python3-qtpy-common > Drop python3-qtpy entirely > Make python3-qtpy-pyqt5 Provide python3-qtpy > Have each of the python3-qtpy-$API packages Depends: python3-qtpy-common > > That approach means python3-qtpy-pyqt5 gets installed as part of upgrades > for existing users of qtpy with pyqt5 but has a name that fits in with the > others, thus avoiding this problem with implicit pyqt5 usage in the future. > The old name and the Provides naturally go away once Qt5 goes away, leaving > us with the desired end state. An interesting approach, but then "python3-qtpy" is the upstream name of the package, so it would be a shame to lose it, and python3-qtpy-common is not an "obvious" name - it doesn't quite describe what it does. > I think this approach would be an even easier path than the above with less > breakage and avoiding some of the downsides. I would prefer to give maintainers the chance to think about which Qt/PySide packages they actually want, and forcing them to consider it via a bug seems a better way to handle it than quietly doing it behind their backs. (It also means they'll be aware of the change in the qtpy packages.) So I'm minded to stick with your current MR and go for a mass bug filing; here's a proposed text: Package: <PKG> Version: <VERSION> Subject: Transitioning python3-qtpy to python3-qtpy-* dependency packages Severity: important User: python-q...@packages.debian.org Usertags: versioned-transition Dear Maintainer, Your package currently (Build-)Depends on python3-qtpy. Shortly, this package will be split up as follows: python3-qtpy Only the upstream qtpy package, with no dependencies on any Qt or PySide packages - note that this will drop all of the Qt5 package dependencies that python3-qtpy currently has. python3-qtpy-qt5 python3-qtpy-qt6 python3-qtpy-pyside6 These metapackages will depend on python3-qtpy and also the appropriate Qt5/Qt6/PySide Python packages. python3-qtpy-qt5 is a drop-in replacement for the current python3-qtpy, but you may wish to use one of the other metapackages instead, or even just use python3-qtpy and specify the particular Qt or PySide packages that you require. The default change to debian/control to maintain the current behaviour without breaking the package in the meantime is to replace the current python3-qtpy dependency with: python3-qtpy-qt5 | python3-qtpy (<< 2.4.1-3) but this could be replaced with, for example, python3-qtpy-pyside6 | python3-qtpy (<< 2.4.1-3) to pull in the PySide6 packages instead once python3-qtpy-pyside6 is available. Intended timeline: * 20 December: any packages with this bug still open will be NMU'd to change the dependency on python3-qtpy to the default above. * 30 December: the new python-qtpy 2.4.1-3 package will be uploaded to unstable. Once python-qtpy has migrated to testing, hopefully by the first few days of January, it will then be fine to change the dependency to the appropriate one for your package (and dropping the "python3-qtpy (<< 2.4.1-3)" alternative). Thank you for your support in this. Best wishes, etc. Julian
