[fedora-virt] libguestfs on non-Fedora targets

Howdy. Is there any intention of supporting libguestfs on non-Fedora
targets (given a sufficiently new qemu or kvm)?

As background: I have a bunch of in-house QA infrastructure, which
happens to include my own, internally developed tools intended to
address the same problems as libguestfs. (One tool, for FUSE-mounting
from a guest, used serial ports rather than the vmchannel mechanism, a
buildroot/uClibc embedded userland rather than a stripped Fedora,
qemu-nbd+nbd-client proxied over serial for getting the block device
into the guest, UML rather than qemu or kvm, and a patched ccgfs+FUSE
for getting the guest's filesystem back out onto the host).

Libguestfs is clearly more mature and flexible than my personal hackery,
so I'm looking at migrating to it -- but right now, I'm having trouble
building it for my VM servers' platform, which is effectively RHEL5 with
kvm-85 and a modern host kernel. Specific issues follow:

----

futimens() isn't available on glibc 2.5, and do_touch() doesn't
presently degrade gracefully to a less-capable call without it:

It was necessary to explicitly set OCAMLC=no OCAMLFIND=no (bypassing
build of the ocaml bits) to prevent the build from breaking early,
apparently due to C interface changes between the expected OCaml and the
ocaml-3.09.3-1.el5 which is present. [TODO: more detail]

----
make-initramfs had numerous complaints:

+ it expected /var/lib/yum to exist within the initramfs root, which it
did not
+ library versions mismatched between host and guest: libtinfo.so.5
(from ncurses, needed by /bin/sh) isn't available on RHEL5 natively
(easily worked around), and the glibc versions don't match (not easily
worked around).
+ unless my PATH included /usr/sbin, builds failed with
"/usr/bin/fakechroot: line 107: exec: chroot: not found"
+ rpm %pre scripts all failed due to the previously mentioned version
mismatches.

----

I haven't gotten beyond the last of these issues on account of the glibc
mismatch. Before I proceed -- is my goal reasonable, or am I better off
sticking with my in-house solution for the time being?