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
Richard W.M. Jones
2013-May-30 22:12 UTC
Re: [Libguestfs] Usage of 'no' as external helper
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
Possibly Parallel Threads
- Re: [PATCH] Change fallback name for external supermin helper
- [PATCH] Change fallback name for external supermin helper
- [PATCH 1/2] add run_shell helper
- Re: [PATCH] Mask some package names if appliance is build for SUSE
- Re: Usage of 'no' as external helper