[tryton-debian] Bug#783029: Bug#788087: python-profitbricks-client: Please use a maintained soap library instead of deprecated python-suds.

[Scott Talbert]

On Wed, 8 Jul 2015, Mathias Behrle wrote:

>>>>>> Instead of porting python-profitbricks-client, I would prefer to take
>>>>>> over the maintenance of suds for at least the stretch release and
>>>>>> follow the suds-jurko releases. Some time ago, I already made sure
>>>>>> that python-profitbricks-client works with the Python3 version of
>>>>>> suds-jurko. What do you think?
>>>>>
>>>>> Basically I can not add much to #783029. Indeed there is some recent
>>>>> action from the maintainer side. All efforts to use suds-jurko as a
>>>>> drop-in replacement (or separate package by Lionel) were done, but
>>>>> neither me (nor Lionel who wanted to do the same as you want to do now)
>>>>> finally wanted to turn into a definite upstream for suds-jurko. For me
>>>>> things are quite unchanged, but perhaps you are lucky to be able to
>>>>> revive the contact with Jurko so you can get some feedback about his
>>>>> future plans.
>>>>>
>>>>> Finally I only can recommend to evaluate the porting effort of
>>>>> python-profitbricks-client (and possibly other rdepends of suds) vs. the
>>>>> maintenance effort of suds-jurko. Bug reports filed against rdepends of
>>>>> suds are available at [0]. The result of above said evaluation could of
>>>>> course be influenced by the porting effort needed by other rdepends.
>>>>> Basically they/we all will be thankful, if there is a maintained suds
>>>>> alternative available.
>>>>
>>>> Looking at those bug reports:
>>>> * 2 just removed the suggestion of python-suds
>>>> * The maintainer of congruity (#788082) responded that porting to
>>>> pysimplesoap would not be an easy effort
>>>> * All other maintainers haven't responded yet
>>>>
>>>> Mathias, may become co-maintainer or adopt python-suds? I wait for your
>>>> go before preparing suds-jurko with Python 3 support.
>>>
>>> Hi Benjamin,
>>>
>>> I would prefer the following way:
>>>
>>> 1) Jurko, the maintainer of suds-jurko, was offered, that his package
>>> could take over the name from original suds on Pypi. He didn't make use of
>>> this offer so far. That would have been a good starting point to use
>>> suds-jurko (then suds) as a drop-in for current suds. As this is not the
>>> case I would indeed prefer to keep the projects resp. packages separate. As
>>> the package must go through NEW anyway for Python 3 support, this is the
>>> cleaner way to get suds-jurko into the archive.
>>> Could you please coordinate with Lionel, who prepared already an initial
>>> separate suds-jurko package [0]?
>>> Please let me know ASAP to inform Rdepends about the new package to prevent
>>> evtl. unneeded work on their side (or do that yourself).
>>>
>>> 2) Please add Provides and Conflicts with python-suds (as done by Lionel).
>>> As soon as suds-jurko will hit unstable I will add the Conflicts to
>>> python-suds and change the package description to hint to your package.
>>>
>>> 3) Rdpends of python-suds will be informed to update their Depends to
>>> python*-suds-jurko.
>>>
>>> 4) python-suds will be removed from the archive before the release of
>>> stretch.
>>>
>>> Is this OK for you?
>>
>> I would much prefer to use suds-jurko as drop-in replacement for our
>> current suds, because
>>
>> * suds-jurko is a fork that does not break the API
>
> There may be some probability for this, but Jurko himself didn't give the
> guarantee, that the changes already done didn't affect the API. Do you want to
> provide this guarantee?
>
>> * the original suds upstream is dead
>> * the original suds could reclaim the namespace if upstream was becoming
>> active again
>> * rdepends don't have to change anything
>
> rdepends should use the new upstream explicitly (see above) instead of
> perhaps suddenly failing because of a more or less inadvertised drop-in.
>
>> IMO it makes no sense to rename the Debian binary package to
>> python-suds-jurko when you still run "import suds" instead of "import
>> suds_jurko".
>
> It is not renaming a package, but indeed a new package. Just like the project on
> Pypi is different from the still existing suds.

Hi Benjamin,

I support getting suds-jurko into Debian as well.  I am happy to help 
maintain the package if you would like help.

Thanks,
Scott