On Tue, 2019-09-17 at 20:17 +0200, Pavel Hrdina wrote: > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote: > > I didn't go through the patch, will do that in the next days ... but a > > few things should be considered here: > > - meson >= 0.49.0 basically means the project won't be built on Debian > > < 10, Ubuntu < 19.04 ... which may be a problem for the project, if > > you're following libvirt supported distros; > > Debian 9 has meson 0.37.1 so yes, this will mean you cannot build > upstream libvirt-dbus using distribution packages, but there is > Python3.5 so the possible workaround is to install meson using pip. > > The same applies to Ubuntu and CentOS 7 as well. There is also a > possibility to bundle meson together with our projects but IMHO > installing meson using pip in user mode is a good enough workaround > if someone is crazy enough to run upstream code on these old > distributions. Yeah, this is definitely a conversation that we need to have. Since the idea is to adopt Meson more and more for libvirt-related projects, including libvirt itself, we have to find a balance between the desire to use relatively recent Meson versions[1] and our current platform support policy. How much more work would it be to use a baseline Meson release that is old enough to be available on all our supported platforms? Can that even be done, or there simply is no amount of compatibility code that we can use to make it work? How difficult is it to bundle Meson, and given that Meson's Apache 2.0 and libvirt's LGPL 2.1+ are not compatible can that even be done? I assume a build system such as Meson would probably have an exception for users, but I haven't checked. More in general, as we look at introducing in the libvirt ecosystem technology that is faster-moving than what we've historically had to deal with, we might need to change our current stance and just accept the fact that building libvirt on an older distribution might require fetching some of the dependencies from side channels such as third-party repositories or language-specific package managers, especially when "older distributions" in this case includes the *latest* Ubuntu LTS release, which is not set to be replaced with a newer version before at least six months! Basically the work you're doing in libvirt-dbus[2] will for better or worse inform the way the entire libvirt ecosystem will deal with the same challenges a few months down the line, so we should make sure we don't just hand-wave concerns away because "it's just libvirt-dbus" but spend some time considering the implications instead. [1] Meson 0.49.0 was released in December 2018, nine months ago. [2] Which is awesome, by the way! Thanks for putting the time in :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
