Am 07.06.21 um 12:48 schrieb Simon Lees:
On 6/7/21 12:21 AM, Ben Greiner wrote:
Am 14.04.21 um 22:16 schrieb Luca Beltrame:
In data mercoledì 14 aprile 2021 14:46:24 CEST, Ben Greiner ha scritto:
As mentioned before, I would favor devel:languages:python:pyqt. I volunteer to participate in maintaining the project, but of course it is at the discretion of the existing maintainers. I'm not sure if I worded it correctly, but I was in agreement with d:l:p:pyqt.
Despite repeated inquiries, Matej is still vetoing d:l:p:pyqt. [1]
* SIP and PyQt[56] are not from the same developers as Qt or KDE * SIP (python-sip) has nothing to do with KDE:Qt* * PyQt[56] is the main but not the only consumer of SIP - Thus, following Simon's argument [2], python-qt5*, python-PyQt6* and python-sip* should be in the same devel project. * Qt Libraries are packaged into separate projects for each minor version. * The most recent version of PyQt5 compiles with any Qt5 version. The most recent version of PyQt6 compiles with any Qt6 version. - Thus, putting python-PyQt6 into a KDE:Qt6.X project would be wrong
With the bullet points above, one could argue to put everything into devel:languages:python, but that collides with Matej's veto and Simon's argument. If we can't get d:l:p:pyqt, IMHO the next best thing would be KDE:Qt:PyQt. To me this probably makes slightly more sense then d:l:p:pyqt, d:l:p has never contained all our python packages, packages that are mostly bindings of C / C++ libraries have always tended to live with those libraries.
That's true. It makes sense when the bindings are closely connected to the library. Especially for python-foo subpackages which are built within the same foo.spec as the libfoo.so.* C/C++ library. However: * SIP is a "generic" tool to generate Python bindings for arbitrary C/C++ libraries. E.g. Qt, some Cura libraries, Poppler-Qt5, Calibre. Admittetly they are all *somehow* related to Qt or at least use Qt, but that is not a natural law. * On the other hand, whenever there is a new release of PyQt6, it is very likely that it comes wit a new release of SIP --> they should be in the same devel project. * PyQt[56] does not follow the same release cycles as Qt [56].* --> we need a separate subproject. * The name of the devel subproject is independent of the repository path where the outside packages come from. Unless they are in the same subproject, all python packages with a GUI and importing PyQt5 get their python-qt5 from Factory in any of the discussed scenarios. * Why do we have d:l:p:aws, d:l:p:azure, d:l:p:mailman, d:l:p:numeric and so on? With your reasoning, their complete content should go to Cloud:Tools, server:mail, science, etc. Ben