On 09/14/2017 02:42 PM, Daniel P. Berrange wrote: > On Thu, Sep 14, 2017 at 01:41:08PM +0200, Michal Privoznik wrote: >> Currently, we require 0.9.11. However, some APIs are missing >> there and thus sanity check fails: >> >> DEBUG: /usr/bin/python sanitytest.py build/lib.linux-s390x-2.7 /usr/share/libvirt/api/libvirt-api.xml >> DEBUG: FAIL virStream.sparseRecvAll (Python API not mapped to C) >> DEBUG: FAIL virStream.sparseSendAll (Python API not mapped to C) >> DEBUG: error: command '/usr/bin/python' failed with exit status 1 >> >> I'm not sure how to fix that so raising minimal required libvirt >> version is the solution. >> >> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> >> --- >> setup.py | 2 +- >> README | 2 +- >> libvirt-override.c | 149 ----------------------------------------------------- >> 3 files changed, 2 insertions(+), 151 deletions(-) >> >> diff --git a/setup.py b/setup.py >> index f33ff1a..f929eb2 100755 >> --- a/setup.py >> +++ b/setup.py >> @@ -17,7 +17,7 @@ import re >> import shutil >> import time >> >> -MIN_LIBVIRT = "0.9.11" >> +MIN_LIBVIRT = "3.4.0" > > NACK, we cannot do this - it will break many people and apps (OpenStack > in particular) who expect latest libvirt on pypi to work with historical > C libs. I don't know how pypi works, but if somebody distributes just libvirt-python and doesn't ship libvirt.so too, such process is broken already because libvirt-python could have been compiled with one version of libvirt while user might be running a different one. So shipping libvirt.so is the only way. And since libvirt-python doesn't add any new features compared to bare libvirt, why on earth would somebody want to run latest libvirt-python but an ancient libvirt? It doesn't make much sense to update one without other. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
