[libvirt] [libvirt-glib PATCHv5 7/7] gobject: Add wrapper for virNetworkGetDHCPLeases

Zeeshan Ali (Khattak) zeeshanak at gnome.org
Wed Jul 8 14:37:43 UTC 2015

On Wed, Jul 8, 2015 at 2:27 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Wed, Jul 08, 2015 at 01:13:09PM +0100, Zeeshan Ali (Khattak) wrote:
>> On Wed, Jul 8, 2015 at 11:11 AM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> > On Tue, Jul 07, 2015 at 05:27:39PM +0100, Zeeshan Ali (Khattak) wrote:
>> >> Hi all,
>> >>
>> >> Christophe pointed out that this and the previous patch binds API that
>> >> was added an year ago:
>> >>
>> >> commit:  03e0e79e07622496522609741734c2fdcacb5bf2
>> >> Author: Nehal J Wani <nehaljw.kkd1 at gmail.com>
>> >> Date:   Tue Jun 24 02:31:49 2014 +0530
>> >>
>> >>     net-dhcp-leases: Implement the public APIs
>> >>
>> >>     Introduce 3 new APIs, virNetworkGetDHCPLeases, virNetworkGetDHCPLeasesForMAC
>> >>     and virNetworkDHCPLeaseFree.
>> >> ---------------
>> >>
>> >> While I think 1 year old is pretty old enough to justify bumping the
>> >> dep to that version, Christophe thinks its still too soon. I'd hate to
>> >> go through the trouble of adding ugly #ifdef around these new API but
>> >> if others (I guess mainly Dan?) agree with Christophe, I can do that.
>> >
>> > 1 year being old/not old is not a very useful/convincing argument. What
>> > is more interesting is what (supported) distros are shipping (f21, el7,
>> > oldest ubuntu LTS shipping libvirt-glib, debian, ...).
>> For the record, I don't think upstream development should depend on
>> when distros decided to upgrade packages and their release cycles.
> Ok, I'll call you next time I need to get something newish to work with
> the RHEL6 glib ;)

glib is much lower level and libvirt-glib isn't about binding it so
its very different case.

>> Also keeping in mind that it makes very little
>> sense to upgrade libvirt-glib and not libvirt since libvirt doesn't
>> break any ABI/API.
> Generally speaking, there could be security issues, critical bugs in
> Boxes which require a libvirt-glib update to be fixed,

That is why we roll out bug fix releases to stable releases and try
our best not to bump any deps while doing so. If there is a bug fix in
a newer release thats not made available for an older release, distros
are extremely unlikely to simply upgrade to latest release but rather
back port those fixes since new release would also bring along new
features (and therefore bugs).

> ... where
> upgrading just libvirt-glib would be much more convenient than upgrading
> the whole stack. So all in all, this is just a tradeoff to make between
> making our life easier, and (potentially) making distributions life easier.

Surely we need to meet somewhere in between. If Ubuntu or Debian would
for example not upgrade their libvirt for many years to come, would we
keep wasting our time on adding ugly hacks upstream for them?


Zeeshan Ali (Khattak)
Befriend GNOME: http://www.gnome.org/friends/

More information about the libvir-list mailing list