[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging of suds-jurko (was: suds)

On Jul 01, 2014, at 01:10 PM, Mathias Behrle wrote:

>The first tests on suds-jurko are looking very promising. I built the package
>succesfully as a drop-in replacement for the current python-suds package. It
>builds correctly for python2 and python3 with all tests. I tested part of the
>functionality for python2, all was working well. The maintainer of suds-jurko
>is very active and responsive.

Will a Python 3 compatible suds library allow us to make progress on #732644
without rewriting bts to use REST+JSON <wink>?

>1) Can I drop in the suds-jurko fork into the current suds package as
>proposed by Jordan?

Given that suds on PyPI hasn't been updated in almost 4 years, I think we can
reasonably assume its upstream is defunct.  We had a sort of analogous
situation with setuptools, but the distribute and setuptools upstreams did
eventually merge back together.

A counter example might be oauth which was also abandoned upstream and for
which a new upstream called oauthlib was released.  However, in that case, the
replacement was *not* API compatible, so it made sense to make it a different
Debian package.

I don't really have a strong opinion, as I can see both sides of the coin.
You're *probably* safe just taking over the source package, but if you woke up
tomorrow with an extra dose of paranoia, then you might favor a new source
package, which also wouldn't be objectionable, albeit more work to transition

>2) If not 1) what would be the best alternative?
>In this case I would plan
>- a new python-suds-jurko package, conflicting with python-suds
>- filing bugs to rdepends to use the new package
>- removing the old package as soon as possible

Yep.  It's a bit ugly though (I don't like the -jurko blarg).  Oh well, do
what you think is right.


Attachment: signature.asc
Description: PGP signature

Reply to: