Comment 5 for bug 524148

I'm not entirely sure. Both represent different classes of maintenance issues. I chose to patch the source on build because from the documentation I found I had the impression that CDLL matched a specific API, rather than a specific ABI, and doing it this way allows the ABI to change without API changes, and track it better. What I didn't do, but would be a good extension, is to write a python test-case that exercises the CDLL calls in X11.py and run that test suite during build, so that the package fails to build if the calls cannot be satisfied: this, in combination with the dynamic patching, should cause a behaviour similar to that found with native C clients of the libraries.

Another reason to choose to patch the source at runtime was to follow the upstream model: as the source does not specify any specific library version, it is presumed that it is known to work with a number of versions (this is certainly the case for a lot of C clients, so I don't know why it would be diffferent for python CDLL): using the dynamic patch stays closer to the intent of the upstream code whilst working around some of the inconveniences that this caused in the way Ubuntu packages are organised.