Excerpts from Oxan van Leeuwen's message of Sun Apr 03 05:43:27 -0700 2011: > # wheezy not affected as this bug blocks python-gearman from migrating > tag 620469 + sid > thanks > > I see three solutions for this problem: > > (A) Add Conflicts against each other. > This prevents users from installing the packages together, which normally > isn't needed as they provide the same functionality. It isn't optimal > however, as in the future it might be possible that there are programs > that > depend on one of these libraries and that need to be co-installable. > > (B) Rename the python module in one of the packages. > This would be the best solution, but it is a backwards-incompatible break > and every reverse-dependency needs to be patched to use the renamed API. > > (C) Drop the __init__.py from one of the packages. > The two modules are actually co-installable and usable, as they don't use > the same namespace: python-gearman.libgearman uses gearman.libgearman, > while python-gearman uses just gearman. The __init__.py from > python-gearman can't be dropped as it imports the primary API into the > gearman namespace. python-gearman.libgearman seems to be functional > without > the __init__.py, but I'm not 100% sure. Also having two packages providing > the same Python package is confusing. >
Oxan, thanks for the quick response. I opened this issue upstream: https://github.com/Yelp/python-gearman/issues/#issue/11 I think the way to go is to drop __init__.py from python-gearman.libgearman, and make it depend on python-gearman, since it is a sub-module of the gearman namespace. I haven't been able to make gearman.libgearman work properly without the __path__ changes, though I'm not entirely sure why as I'm sort of a python extension novice. If anyone *can* make that work, then we don't even need the change suggested above. > I think the best we can do at this point is A, given the side-effects of the > other options. I'll implement that in python-gearman (which should be enough) > if nobody objects. Yeah I was thinking of doing the same in the python-gearman.libgearman, but I think since its temporary we can just leave it in python-gearman until the necessary changes can be made for python-gearman.libgearman to depend on python-gearman. With the Conflicts on one side, I think we can close this bug, and open a new wishlist bug to implement the dependency relationship. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
