Re: [libvirt] [libvirt-python][PATCH] maint: Require libvirt-3.4.0 at least
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(a)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