Re: [Libguestfs] [PATCH supermin v4] Supermin 5 rewrite.
On Fri, Mar 28, 2014 at 07:49:47AM +0100, Olaf Hering wrote:
On Tue, Feb 25, Richard W.M. Jones wrote:
> configure.ac | 27 +-
Commit breaks expectations during pkg build.
Before commit 29eb7d6a0 ("configure: Use AC_PATH_PROG for package
manager binaries.") it was possible to pass an executable via
environment like "env ZYPPER=zypper ./configure $args". The result is
that the string "zypper" is called by supermin, even if it was not
installed at build time. This reduced the dependency chain.
Now its required to pass the absolute path, like "env
ZYPPER=/usr/bin/zypper ./configure $args". The result is that at runtime
the user is forced to use the built-in string "/usr/bin/zypper". Looks
like over there the concept of PATH got lost, not just in supermin.
What is the reason for this change, what does it fix?
The comment added in this commit does not really explains the why, just the what.
Since Oct 2013 libguestfs has had this policy about AC_PATH_PROG vs
AC_CHECK_PROG:
# NB: AC_CHECK_PROG(S) or AC_PATH_PROG(S)?
# Use AC_CHECK_PROG(S) for programs which are only used during build.
# Use AC_PATH_PROG(S) for program names which are compiled into the
# binary and used at run time. The reason is so that we know which
# programs the binary actually uses.
This was added because of a RHEL bug where a user had installed some
extra software in /usr/local/bin. This broke libguestfs and caused a
RHEL support issue.
The thinking behind the change (and this one in supermin) is that if
libguestfs/supermin requires a specific binary, then it should encode
the full path of that binary into the library so it always calls the
correct, tested binary, and not some other binary that the user
happens to install.
I guess the question from me is why the user would want to use zypper
from $PATH, instead of zypper which supermin had been configured and
tested against? Is it common that SUSE users want to try different
versions of zypper?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW