[Libguestfs] [PATCH] Make appliance-building work on systems with default library search paths differing from the appliance's
Nix
nix at esperi.org.uk
Sun Oct 24 12:06:51 UTC 2010
On 24 Oct 2010, Richard W. M. Jones said:
> This needs to be fixed in febootstrap. I'll have a look at it
> tomorrow.
I thought so: this was a more a heads-up that the problem existed than a
neat patch. A similar uname-inspecting trick followed by resetting
LD_LIBRARY_PATH should work (though you shouldn't just terminate it with
: as I did, as this means to search the current directory if
LD_LIBRARY_PATH is unset. Something like
${LD_LIBRARY_PATH+:}${LD_LIBRARY_PATH:-} would be better.)
> Any reason not to be building with debootstrap + debirf on Debian? It
> produces a native Debian appliance, and modulo continual bugs in
> debootstrap & debirf it does work.
Firstly, I wanted to see if it worked :)
Also, although I have a Debian system, my VM host is actually an LFS box
running eglibc with Debian's patches applied. Like Debian, I happen to
think that /lib is the right place for the machine's 'native bitness',
and if you want a specific bitness (which you rarely do), you should
look in /lib32 and /lib64 explicitly.
Also also, the last time I ran debootstrap it chewed the line for hours
(much longer than febootstrap) then failed to give me a working system
at the end of it. At least I know febootstrap is a tested and working
appliance-builder! ;} i.e., those continual bugs don't exist (at least
not to such a degree) in febootstrap.
More information about the Libguestfs
mailing list