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.
(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.
(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.
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.
I think this approach would be an even easier path than the above with
less breakage and avoiding some of the downsides.
What do you think about this approach?
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ [email protected]
Debian Developer http://www.debian.org/ [email protected]
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
