On Wed, Sep 18, 2019 at 11:30:14AM +0200, Andrea Bolognani wrote: > 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. The licensing is a non-issue. Source tar.gz can contain stuff under as many different licenses as we wish. The license compatibility requirements affect code that goes into the various programs, libraries that are built/installed. No meson code gets built into the libvirt dbus binaries. We certainly could bundle meson with them, but given that in very short time we're going to have libvirt, libvirt-dbus, osinfo-db-tools, libosinfo, gtk-vnc, spice-gtk all using meson, bundling meson in the individual tarballs feels like a waste of time to me. Distros are better off packaging a newer meson just once. If they can't/won't upgrade their existing meson, then the distros can still bundle a newer meson tarball in the individual source packages they build. IOW, I think we should just go with whatever is needed to do a good job with meson usage from upstream POV, and let distros jump through whatever hoops they need downstream. For our CI system, we can just install newer meson ourselves to satisfy the version apps if we want to keep testing on these distros, which I think we should. With RHEL-7.7 shipping a python 3 package, we don't have the py2 problem anymore there. 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
