On Fri, Nov 13, 2020 at 8:14 AM Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > > On Fri, 2020-11-13 at 12:37 +0100, Pavel Hrdina wrote: > > On Thu, Nov 12, 2020 at 10:40:02PM +0100, Olaf Hering wrote: > > > Since meson does not support environment variables it seems the > > > only way to address this is to introduce an option in > > > meson_options.txt for each runtime executable. > > > > > > Will such change be accepted? > > > > This would be one way how to address runtime executables, currently we > > have a lot of them. These executables are checked in order to > > enable/disable some libvirt feature but is used only in runtime: > > > > parted, bhyve, bhyvectl, bhyveload, mount, umount, mkfs, pvcreate, > > vgcreate, lvcreate, pvremove, vgremove, lvremove, lvchange, vgchange, > > vgscan, pvs, vgs, lvs, (collie|dog), vstorage, vstorage-mount, zfs, > > zpool, numad > > > > This one is even more broken as if we don't find it during build time it > > is set to empty string and never checked in our code: > > > > showmount > > > > These are checked during build time but if not present they are set to > > known absolute path: > > > > qemu-bridge-helper, qemu-pr-helper, slirp-helper, dbus-daemon > > > > And we have a list of optional_programs that are checked during build > > time and if not present they are set to the name of the executable and > > resolved during runtime from $PATH. > > > > The last executable, pkcheck, is not used during build and in runtime. > > We only check its presence to enable/disable polkit support. We should > > be able to simply drop this check and figure out the presence of polkit > > using DBus only as we do for machined or logind and other DBus services > > that we use. > > > > All of this was copied from autoconf except for the fact that it is no > > longer possible to use ENV variables. > > > > I think we need to unify the process how we handle runtime executable > > dependencies and possibly add meson options for them. > > As another data point, Debian currently carries a patch[1] which > allows us to enable the ZFS driver without installing the ZFS > packages in the build environment: this is necessary because, due to > its license, ZFS is kept outside of the main Debian repository. > > Being able to use something like > > -Dprog_zfs=/sbin/zfs -Dprog_zfspool=/sbin/zfspool > > to achieve the same result would allow us to drop that patch, which I > would be *extremely* happy about :) > > > [1] https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/master/debian/patches/debian/Set-defaults-for-zfs-tools.patch The way I solved *that* specific problem was to use zfs-fuse at build-time and have runtime work with either implementation. That should work for you too, since Debian has zfs-fuse in main. -- 真実はいつも一つ！/ Always, there's only one truth!
