Re: [libvirt] Why using AC_PATH_PROG to detect the location of run-time external programs

On 03/19/2014 03:15 PM, Howard Tsai wrote: It is only hard-coding the default location of the tools. You are free to override that, by using ./configure OVSVSCTL=/path/to/the/destinat*ion/ovs-vsctl to force the binary to be built with the hard-coded location you plan on using in your installation, or use ./configure OVSVSCTL=ovs-vsctl to force libvirtd to do a PATH lookup every time. Deferring the decision to libvirtd.conf might be feasible, albeit more complex. Propose a patch, and we'll look at it. But for now, the default is good enough, and over-ridable at configure time, so it's not something that I'm personally bothered by enough to write a patch myself. By the way, we DO prefer hard-coded locations over PATH lookups, because PATH lookups can result in odd behavior when two people run qemu:///session with different PATH, and where the lookup may pick up a different binary for the two users. Configuring a hard-coded location requires a bit more planning, but is more secure - and since MOST users go with pre-built distributions, the hard-coded binaries can be guaranteed* to be present (for example, the rpm files used by Fedora guarantee that for any tool where we hard-code the location into the libvirt binary as living in /usr/bin will also be a prereq of the package, so that if you install libvirt, you also install the prereq packages that libvirt will try to use). [*Of course, if you ever hit a case where this guarantee is not met, file a bug against the distro to inform them of the missing dependency] Again, that's a matter of setting up OVSVSCTL on your dev box to match the location where the binary will be present on your test box. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org