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.