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@redhat.com>
---
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@redhat.com], [], [http://libvirt.org])
+AC_INIT([libvirt-dbus], [1.2.12], [libvir-list@redhat.com], [], [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
SYSTEMD_REQUIRED=211
AC_SUBST([LIBVIRT_REQUIRED]) dnl used in the .spec file
AC_SUBST([SYSTEMD_REQUIRED]) dnl used in the .spec file
--
2.14.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> > --- > 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@redhat.com], [], [http://libvirt.org]) > +AC_INIT([libvirt-dbus], [1.2.12], [libvir-list@redhat.com], [], [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. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> > > --- > > 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@redhat.com], [], [http://libvirt.org]) > > +AC_INIT([libvirt-dbus], [1.2.12], [libvir-list@redhat.com], [], [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. 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. Pavel > > 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> > > > --- > > > 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@redhat.com], [], [http://libvirt.org]) > > > +AC_INIT([libvirt-dbus], [1.2.12], [libvir-list@redhat.com], [], [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. > 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 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> > > > > --- > > > > 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@redhat.com], [], [http://libvirt.org]) > > > > +AC_INIT([libvirt-dbus], [1.2.12], [libvir-list@redhat.com], [], [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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.