On Mon, Mar 19, 2018 at 02:16:15PM +0000, Daniel P. Berrangé wrote: > On Mon, Mar 19, 2018 at 02:56:49PM +0100, Pavel Hrdina wrote: > > On Mon, Mar 19, 2018 at 01:42:11PM +0000, Daniel P. Berrangé wrote: > > > On Mon, Mar 19, 2018 at 10:30:49AM +0100, Pavel Hrdina wrote: > > > > We will require libvirt to have at least the same version as > > > > libvirt-dbus. The 1.2.12 version is the lowest one which we will > > > > support since it introduced virDomainDefineXMLFlags() and we don't > > > > have to support the non-flags APIs. > > > > > > > > Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> > > > > --- > > > > configure.ac | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index df1a375..ba397ca 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -1,4 +1,4 @@ > > > > -AC_INIT([libvirt-dbus], [0.0.1], [libvir-list@xxxxxxxxxx], [], [http://libvirt.org]) > > > > +AC_INIT([libvirt-dbus], [1.2.12], [libvir-list@xxxxxxxxxx], [], [http://libvirt.org]) > > > > > > > > AC_CONFIG_SRCDIR(src/main.c) > > > > AC_CONFIG_AUX_DIR([build-aux]) > > > > @@ -11,7 +11,7 @@ AC_USE_SYSTEM_EXTENSIONS > > > > > > > > AM_SILENT_RULES([yes]) > > > > > > > > -LIBVIRT_REQUIRED=1.2.8 > > > > +LIBVIRT_REQUIRED=AC_PACKAGE_VERSION > > > > > > This feels a bit odd to me - what will you set the AC_INIT version to > > > if you want todo 5 releases of libvirt-dbus, without bumping the min > > > required version of libvirt. > > > > > > I can understand having the libvirt-dbus versions be set in lockstep to > > > libvirt versions in AC_INIT, if you plan to always do a libvirt-dbus > > > release on the 1st of the month at same time as libvirt, but even then > > > I doubt you'd want to set min required libvirt to match. > > > > The reasoning behind it is that I would like to avoid using > > #if LIBVIR_CHECK_VERSION() like we do in libvirt-python and strictly > > depend on libvirt version that libvirt-dbus will be written for. > > Wanting to avoid conditional version checks is a totally reasonable > thing todo, so no objection to that. I'm just not sure it makes > sense to tie the version numbers together unless you jump straight > to the very latest version 4.2.0 right now and bump it again on > each release. That was my original idea to not tie the libvirt-dbus version numbers together with libvirt. Jumping straight to the latest version would mean more conservative distribution would not be able to introduce libvirt-dbus unless they bump libvirt itself or they adds downstream only patches to remove non-existent APIs in the old libvirt. That's why I changed my mind to follow libvirt versions and start with some reasonably old version, implement all the libvirt APIs till that version and make a release. After that we would implement remaining APIs based on the libvirt releases where new APIs was introduced and match libvirt-dbus releases accordingly. > > The other solution is to not use XML files for interface but have > > the interface specified directly in the code in order to be able to > > generate correct introspect data depending on what was compiled in. > > > > Since this is more or less a binding, I think it would be better to > > follow libvirt versions like we do with other bindings. > > > > This was the first idea that I had and now I realize that it's not > > good one. I can change it back, however we need to make sure to > > properly update the libvirt required version once we implement new > > libvirt APIs. > > You could write a 'make check' rule to validate this. eg run > > eu-readelf -a libvirt-dbus | grep LIBVIRT > > this will give you all the ELF versions from libvirt that are > used by libvirt-dbus. You can thus check if you've used a > version that is newer than the value listed in configure.ac Nice, TIL :). Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
