Bug in third-party dependency creates python packaging dilemma

I'm a developer on a software project for Linux that uses Python and PyGTK. The program we are writing depends on a number of third-party packages that are available through all mayor distro repositories. One of these is a python binding (written in C) that allows our program to chat with a common C library. Unfortunately, there's a bug in the bindings that affects our program a great deal. A fix/patch was recently presented, but hasn't been committed yet. We want to include this fix as soon as possible, but are unsure that the best course of action would be.

Based on the scenario I described, we figured we have the following options. Hopefully someone can give more insight or maybe point us to a solution we haven't considered yet

• Wait for the python bindings to be updated. The problem with this is that we have no way of knowing when the update would be accepted into distribution repositories, or even if it will be backported to earlier releases.
• Include a modified version of the python bindings including the fix with our program and have users compile it on installat开发者_如何转开发ion. This would provide a burden for packagers as every version of every distribution would link against another version of the C library.
• Rewrite our program in C++ and avoid dealing with python bindings all together. Yep, actually considering this hehe.
• Keep the ugly hack we have in place intact. Not preferable obviously as it is, well, an ugly hack

Thanks in advance!

---

As long as the ugly hack works, use it. It will have drawbacks local to your package. Additionally, you can phase it out (significantly) later by requiring a bug-free version of your dependency, when it is released and is available for some time so that distros have a chance to start shipping it.