On Wed, Jan 20, 2010 at 10:32:03PM +0100, Matthias Bolte wrote: > 2010/1/20 Daniel Veillard <veillard@xxxxxxxxxx>: > > Pro: it's more flexible > > Cons: it's less rigid > > > > :-) > > > > I think it's fine since in the majority of cases that code will be run > > by libvirtd, which as a daemon will have a relatively well defined and > > contained PATH . Like when a rogue shared library si available in some > > common place that lead to very painful debugging when an user has a > > problem, rather than the rather straighforward error about a missing > > binary the current version. It's a bit of a double edged sword, but in > > that case I think it's fine. But I could see how others could disagree > > > > ACK from my POV, > > > > Daniel > > > > Actually this code will never be executed outside of libvirtd, because > it's executed as part of the QEMU state driver startup only. > > Well, I wouldn't compare this to a "rogue shared library" or > LD_PRELOAD stuff, because you can use virsh capabilities for example > to see if it picks up unexpected QEMU binaries. So this shouldn't make hum, that's true. > debugging harder. You need to know where to look for information when > debugging, that's right. > > Also this make libvirt behave more like the user expects it to. There > were some people on the mailing list and on IRC lately that had > problems with the hardcoding of /usr/bin. They expected libvirt to > pick up their QEMU binaries in /usr/local/bin for example. Okay :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list