Am 21.02.21 um 13:30 schrieb Simon Lees:
Firstly Cross posting to factory as there is a chance not everyone who
needs to read this is on packaging@ (more for packaging help and support)
In this case the instructions in the project description of
devel:languages:python need an update and an appropriate mention of the
factory mailing list in the wiki  should be added.
... and of course I hit the send button with the wrong sender tag again,
so if a moderator decides to let that through instead of discarding, you
get this mail up to 4 times now m-(
On 2/20/21 6:18 AM, Ben Greiner wrote:
python-sip, python-qt5 and co. have always been kind of a foreign body
to C++ focused KDE:Qt5. May I propose to create
devel:languages:python:pyqt and put related packages into that one?
Maintainers could be python and QT/KDE people together.
Its worth noting that
currently python-qt etc is staged and bought up
with each Qt version
example so how well this change will work with the existing Qt setup I
guess we will have to wait for the KDE/Qt people to answer.
It's a long standing myth, but not true [2, 3]. And of course all those
subprojects can continue to link to their preferred package version.
Strangely, many Qt5 packages in Factory don't even have an assigned
devel project at all . python-qt5 has devel project KDE:Qt5, btw.
> ## List of existing packages to be considered:
> ## New packages to be created (using the PyPI names as naming template
> instead of continuing the legacy rpm package names. Of course
> appropriate `Provides:` tags for the rpm names should be included):
> python-PyQt6 (also providing python-qt6)
> python-PyQt6-sip (also providing python-qt6-sip)
> python-PyQt6-3D (also providing python-qt3d-qt6)
> python-PyQt6-NetworkAuth (also providing python-networkauth-qt6)
> python-sip6 (see below)
> ... and more of the family as they are released upstream.
> ## Not PyQt but closely related or the "competitor":
> python-PySide2 (currently python3-pyside2)
> There is also SIP v6 now. Some packages still depend on SIP v4 (e.g.
> cura libraries) or use the legacy features of SIP v5 (e.g. the sip5
> executable), so we can't just have a single up to date python-sip. After
> some discussion with DimStar a few days ago, I propose, what I call the
> "tornado approach", because it is what python-tornado is doing right now:
> * Have python-sip4, python-sip5, python-sip6, all providing python-sip
> * Make python-sip a meta package and have it require the currently
> preferred default (python-sip5 at the moment).
> * Have the appropriate `Prefer:` tags in prjconf.
> Thoughts and comments welcome!