Moving libcrypto.so.* back to /lib
Richard W.M. Jones
rjones at redhat.com
Fri Apr 9 16:54:21 UTC 2010
On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones <rjones at redhat.com> said:
> > libguestfs builds its appliance on the fly by concatenating together
> > files [library files, binaries and data files] from the host. We
> > express this requirement by mapping the location of those files into
> > dependencies.
> Why can't it just depend on libcrypto.so.<vesion>, and then use the
> linker to find the libraries at run-time?
Because it's not linking with the library, it's copying it (along with
many other non-library-like files) into an appliance.
> Depending on fixed paths seems like a bad idea.
It depends on fixed paths because fixed paths are used to build the
appliance. Therefore the dependencies tell us when something isn't
going to work at runtime, instead of having the package silently
broken by changes such as the one discussed in the OP.
Now you may think that this is a bad way to build an appliance, but no
one has come up with any better ideas for that so far.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
More information about the devel