[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