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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
