[libvirt] [PATCH python 7/7] Require libvirt native version matching py version by default

[Daniel P. Berrange]

On Thu, Jan 11, 2018 at 06:00:34PM +0100, Jiri Denemark wrote:
> On Thu, Jan 11, 2018 at 16:43:39 +0000, Daniel P. Berrange wrote:
> > Although we're capable of building against any libvirt >= 0.9.11, 99% of the
> > time we want RPM builds to be done against matching libvirt version, otherwise
> > we might silently build against an unexpected/wrong version.
> > 
> > Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
> > ---
> >  libvirt-python.spec.in | 2 +-
> >  setup.py               | 3 +--
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libvirt-python.spec.in b/libvirt-python.spec.in
> > index 0087c78..6afa6f8 100644
> > --- a/libvirt-python.spec.in
> > +++ b/libvirt-python.spec.in
> > @@ -35,7 +35,7 @@ Source0: http://libvirt.org/sources/python/%{name}-%{version}.tar.gz
> >  Url: http://libvirt.org
> >  License: LGPLv2+
> >  Group: Development/Libraries
> > -BuildRequires: libvirt-devel >= @C_VERSION@
> > +BuildRequires: libvirt-devel >= %{version}
> 
> Shouldn't we even restrict this to ==? If libvirt-python is built
> against newer version of libvirt, its generator may provide incorrect
> implementation for new APIs which need to be implemented manually. And
> only new enough libvirt-python will have these new APIs in the override
> list.

Hmm, yes, that's a good point. We don't officially support building old
python against newer libvirt.  We probably ought to validate that in the
generator too rather than leave the user to get bizarre error messages
or badly generated code.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|