Re: [libvirt PATCH 00/17] drop meson checks for runtime binaries

On Mon, Apr 19, 2021 at 01:59:52PM +0100, Daniel P. Berrangé wrote: > On Mon, Apr 19, 2021 at 02:50:13PM +0200, Michal Privoznik wrote: > > On 4/19/21 2:24 PM, Neal Gompa wrote: > > > On Fri, Apr 16, 2021 at 3:13 PM Pavel Hrdina <phrdina(a)redhat.com&gt; wrote: > > > > > > > > > > > > > > I don't think this is a good "cleanup" to do. Having these checks is > > > useful since without them, we'd blindly build modules that possibly > > > wouldn't work because we haven't verified that those dependencies > > > exist. People do install from source into runtime (I don't, but people > > > do), and it's useful for making sure all the necessary dependencies > > > are captured for runtime use at build-time for package builds (I've > > > caught mistakes because of these). > > > > To be fair though, some cleanups Pavel did are worth merging (e.g. couple of > > first patches that fix comments or remove unused functions) regardless of > > ... > > > > > > > > So I NACK the whole series. > > > > > > > > > > this NACK. What I am worried about is that usually, when a distro builds > > libvirt package a path to a runtime binary will be recorded (e.g. DNSMASQ > > will be expanded to /usr/sbin/dnsmasq and compiled in). This way, we will > > try to find "dnsmasq" in PATH, which may work for qemu:///system, but may > > lead to unexpected results for qemu:///session because for instance I > > override PATH for my regular user so that a directory with my helper scripts > > comes first. Let's hope that I won't pick wrong name for my scripts. > > I think that's actually the desirable situation for libvirtd running > as non-root. If the user overrides a system binary with an alternate > impl, it is right that we honour that. Agreed. > I think we ought to consider two parts to this series - honouring $PATH, > and probing at meson time. We can have the former, without changing > the latter, so we still get feature auto-detection at build time to > avoid uncessarily building stuff that's not appropriate for the OS > in question. I was about to propose that as well. We can have check for some binaries in meson to figure out if something should be enabled or not for features that have value set to "auto" so by default meson would do the "right" thing. But if a user/developer explicitly enables some feature, for example iscsi storage we should not error out if the binary is missing because the code can be compiled without the binary. This would also allow package maintainers to reduce a list of build dependencies that are required. I'll post a v2 with this approach.