[Libguestfs] [PATCH 1/2] lib: Allow db_dump package to be a weak dependency (RHBZ#1409024).

[Richard W.M. Jones]

On Fri, Oct 06, 2017 at 03:11:40PM +0200, Pino Toscano wrote:
> On Friday, 6 October 2017 12:23:00 CEST Richard W.M. Jones wrote:
> > I mostly agree with all of what you say, EXCEPT that in the past we've
> > had cases where people have installed broken binaries on
> > /usr/local/bin and then reported bugs against libguestfs.
> 
> I would consider this situation broken anyway, and as mentioned above
> it will be spotted by looking at the verbose logs (which show the
> executable run, and with my changes they are passed as absolute).

Certainly agreed the situation is broken when someone puts a broken
binary in /usr/local.

> > Therefore at configure time we need to store the actual path of the
> > binaries we want to use (and the binaries that the packager tested
> > against) and we shouldn't search $PATH at runtime.
> 
> The current system though will not prevent any of those mistakes if
> the user builds libguestfs after installing the binaries in /usr/local
> (or anywhere else in $PATH): the configure of libguestfs will pick
> them, and thus back at the issue.

In that situation, the tests will run against those binaries from
/usr/local, and libguestfs will run against those same binaries.
That's fine - we have proved those binaries aren't broken!

But really I'm talking about the majority of consumers who get
libguestfs from their distro.

> Instead, looking them only at
> runtime means the user can just cleanup the broken binaries, with no
> need to rebuild libguestfs later.
> 
> > So some generic mechanism is fine, and looking for binaries at runtime
> > is also fine, but not one which is searching $PATH.
> 
> If $PATH has broken stuff, then it is a bigger problem than just
> libguestfs.  Do not get me wrong: I understand the concern here, but
> IMHO it should be better to just rely on the good status of the system
> (as it is supposed to be), rather than "hacking around it".

I really don't think this is hacking around anything.

It's addressing a problem which has come up in reality.

It's not hacking because the distro packager has built (and one hopes
checked) that libguestfs works against a certain mix of binaries,
namely those provided under /usr/bin by the distro.  The distro is
responsible for those binaries, but not the ones under /usr/local/bin.

I think this is about the integrity of what we ship to the majority of
users.

FWIW I posted a v2 of this patch series (actually, before I saw this
email, because the mailing list is incredibly slow this week for some
reason).  It attempts to address the problem in a way which is simple
yet allows weak dependencies.

Also I posted another patch to address the qemu-img situation which
you mentioned back in your posting in February.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org