Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system
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