Libguestfs - May 2013 - Usage of 'no' as external helper

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?


Olaf

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

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