[libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

Andrea Bolognani abologna at redhat.com
Wed Sep 18 12:55:53 UTC 2019


On Wed, 2019-09-18 at 10:39 +0100, Daniel P. Berrangé wrote:
> 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.

So, to be clear, you're advocating for keeping our list of target
platforms unchanged and exempt Meson specifically from the implicit
requirement we've had so far, which is that all build dependencies
should be installed from distro-provided packages?

I'm not saying that I'm against this, but I think we should at the
very least document this prominently, and ideally get an explicit
thumbs up from a few downstreams because this could negatively
affect their ability to package new libvirt versions.

> With RHEL-7.7 shipping a python 3 package, we don't have the py2
> problem anymore there.

Not having a suitable Python 3 available on the system would
certainly be a much bigger hurdle than not having Meson, so it's
good that we're now in this position, especially with the Python
clock ticking ever so faster...

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list