On Wed, Sep 05, 2012 at 12:46:26PM +0100, Richard W.M. Jones wrote:
 [The context for libvirt users is how to let people do
 'make install' without having conflicts with installed copies
 of packages.]
 
 On Wed, Sep 05, 2012 at 07:39:37AM -0400, Whit Blauvelt wrote:
 > On Wed, Sep 05, 2012 at 08:07:09AM +0100, Richard W.M. Jones wrote:
 > 
 > > It is possible to run 'make install', but we normally do not recommend
 > > you do that.  To avoid conflicts between other packages, you should
 > > build a libguestfs package for your Linux distro, which is not so
 > > easy.
 > 
 > Is there a goal at least that if a the group of programs including libvirt
 > and qemu-kvm is built and installed from tar, that it should install with
 > internal consistency regardless of underlying distro?
 > 
 > All the distros necessarily lag development here. Sometimes new features are
 > key to a particular deployment. Isn't it a useful goal to produce components
 > such that, if "make install" is used with each of them, the result should
be
 > good? Is that the goal of these related projects?
 > 
 > Now days, for instance, every distro does a good LAMP stack. But earlier in
 > the development of that stack it was often best to compile it from source,
 > due to versions lagging and distro maintainers making assumptions that
 > weren't well honed. In the first few years of any new stack, shouldn't we
 > expect that many sysadmins will be in the same position?
 > 
 > It's best if there's some defined subset of programs whose "make
install"
 > options, by default, will produce a coherent stack. 
 
 I'm not sure how special libvirt & qemu are.  You could try installing
 to a local prefix (I sometimes use "./configure --prefix=$HOME/gnu").
 
 Then you have to sort out the environment variables that need setting.
 
 I don't think libvirt or libguestfs or qemu document what environment
 variables should be set to run an internally consistent local copy
 of the entire libvirt/KVM stack from your home directory.
 libguestfs has the "./run" script which can be modified.
 
 Anyone got any thoughts?  I think it is a genuine concern. 
libvirt will search for QEMU binaries in $PATH. So if you install QEMU
to a custom location, just make sure that location comes first in $PATH.
WRT to libvirt.so <-> libvirtd, the socket path is based on the install
prefix, so if you install libvirt to a non-standard location, you need
to make sure you are using the matched libvirt.so and libvirtd. The
easiest way todo this is just again make sure $PATH reflects your new
install location, and set LD_LIBRARY_PATH so that libguestfs finds the
custom libvirt.so too
Daniel
-- 
|: 
http://berrange.com      -o-    
http://www.flickr.com/photos/dberrange/ :|
|: 
http://libvirt.org              -o-             
http://virt-manager.org :|
|: 
http://autobuild.org       -o-         
http://search.cpan.org/~danberr/ :|
|: 
http://entangle-photo.org       -o-       
http://live.gnome.org/gtk-vnc :|