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@xxxxxxxxxx> > > --- > > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
