Re: [libvirt] [Libguestfs] compile libguestfs 1.19.35
[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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Libguestfs] compile libguestfs 1.19.35
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. And DevStack is doing something similar for OpenStack developers ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Libguestfs] compile libguestfs 1.19.35
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
