[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-factory
Subject:    Re: RFC: New devel project devel:languages:python:pyqt and deal with different SIP versions
From:       Ben Greiner <code () bnavigator ! de>
Date:       2021-06-07 17:24:25
Message-ID: 1729369e-9569-6482-c0d8-37ed54db45a1 () bnavigator ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]