[Libguestfs] Usage of 'no' as external helper

[Olaf Hering]

On Thu, May 30, Richard W.M. Jones wrote:

> On Thu, May 30, 2013 at 10:02:10PM +0200, Olaf Hering wrote:
> > 
> > libguestfs and supermin use 'no' instead of either the basename of the
> > desired application, or 'false', as helper string. This happens when
> > configure does not find things like rpm or supermin during build.
> > 
> > Wouldnt it be more logical to use the basename instead of 'no' so that
> > at runtime one has the chance to install the required packages and in
> > addition get an obvious error message in verbose mode what external
> > helper is actually missing? In my package I force a few things like
> > 'export ZYPPER=zypper' to avoid the unneeded BuildRequires: zypper. But
> > doing that for every binary that maybe called is cumbersome.
> > 
> > I think its best to rely on PATH to let libguestfs and supermin packages
> > find their external helpers at runtime. And one who has a need to
> > actually hardcode absolute paths to external helpers into his
> > libguestfs/supermin binaries can do that by doing the 'export
> > HELPER=/path/to/helper' during his own configure run.
> > 
> > Thoughts?
> 
> I suspect it depends on the application on a case-by-case basis.

I looked just now at configure.ac, there are a few
AC_CHECK_PROG/AC_CHECK_PROGS. I was thinking of supermin and also the
netpbm tools. Now I see the latter are compiled conditionally.

So as you say its not that bad, maybe the "no" for supermin can be
replaced with supermin, the others I will check.


Olaf