[libvirt] [libvirt-python][PATCH] maint: Require libvirt-3.4.0 at least

[Michal Privoznik]

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 at redhat.com>
>> ---
>>  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