[Libguestfs] Usage of 'no' as external helper

[Richard W.M. Jones]

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.

Examples (from libguestfs):

- supermin-helper: This is called at runtime.  If not found at compile
time it's currently set to 'no' which AFAICT leads to a binary build
that could never work except with a fixed appliance [fixed appliance
doesn't need supermin-helper].  This is a bug, I think.

- msgmerge: If not present, localization is disabled.  It doesn't
really make sense to enable this "at runtime".

- db_dump: We conditionally compile some inspection support based on
whether db_dump is found or not.  This may or may not be a bug,
depending on whether you think it's worth inspection carrying around a
lot of code that has to be tested in the db_dump present/not-present-
at-runtime cases.  Also the runtime code would have to check for every
variation of db_dump, because it has lots of different names.

So I think patches are welcome, but they'll have to be reviewed
individually.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top