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

Wed Jul 8 14:12:58 UTC 2015

* Benjamin Drung: " Bug#783029: Bug#788087: python-profitbricks-client: Please
  use a maintained soap library instead of deprecated python-suds." (Wed, 08
  Jul 2015 13:51:29 +0200):

> Am Mittwoch, den 08.07.2015, 13:30 +0200 schrieb Mathias Behrle:
> > * Benjamin Drung: " Re: Bug#788087: python-profitbricks-client: Please use a
> >   maintained soap library instead of deprecated python-suds." (Wed, 08 Jul
> > 2015 11:39:52 +0200):
> > 
> > > Am Dienstag, den 07.07.2015, 13:21 +0200 schrieb Mathias Behrle:
> > > > * Benjamin Drung: " Re: Bug#788087: python-profitbricks-client: Please
> > > > use a maintained soap library instead of deprecated python-suds." (Thu,
> > > > 02 Jul 2015 19:39:17 +0200):
> > > > 
> > > > Hi Benjamin,
> > > > 
> > > > > Am Montag, den 08.06.2015, 14:03 +0200 schrieb Mathias Behrle:
> > > > > > Package: python-profitbricks-client
> > > > > > Severity: important
> > > > > > User: maintainers at debian.tryton.org
> > > > > > Usertags: migrate-suds
> > > > > > 
> > > > > > Dear maintainer of python-profitbricks-client,
> > > > > > 
> > > > > > your package is listed as a Reverse Depend of the python-suds
> > > > > > package, which is now deprecated due to long time missing upstream
> > > > > > maintenance as well as missing compatibility for Python3 (#783029,
> > > > > > #774948, #782970). It is planned to remove python-suds before the
> > > > > > release of stretch.
> > > > > 
> > > > > suds-jurko seems to be more or less maintained (last upstream commit
> > > > > was yesterday, but the last release is from 2014-01-24) and it
> > > > > supports Python3.
> > > > > 
> > > > > > Please consider to migrate your package to use a maintained soap
> > > > > > library (like pysimplesoap, at the time of writing in NEW).
> > > > > 
> > > > > 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.

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 853 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/tryton-debian/attachments/20150708/412cce31/attachment-0001.sig>