[libvirt] [PATCH 2/3] wireshark: Try a bunch of possible prefixes

[Andrea Bolognani]

On Thu, 2016-10-27 at 10:04 +0200, Viktor Mihajlovski wrote:
> On 26.10.2016 18:08, Andrea Bolognani wrote:
> > If we can't obtain Wireshark's plugindir variable from
> > pkg-config, we fall back to building it ourselves starting
> > from $libdir.
> > 
> > The problem with that is that we have zero insights on what
> > $libdir actually looks like, so we can't simply strip $prefix
> > and call it a day. On the other hand, we have to do *something*
> > or $ws_plugindir will be unusable.
> > 
> > Our solution is to try the four most likely prefixes, and use
> > the first one that matches. It's not perfect, but should be
> > able to cope with all but the weirdest setups.
> > 
> > Worst case scenario, the user can pass --with-ws-plugindir to
> > configure and explicitly provide a suitable installation path.
> > ---
> >  m4/virt-wireshark.m4 | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/m4/virt-wireshark.m4 b/m4/virt-wireshark.m4
> > index 556272a..75786de 100644
> > --- a/m4/virt-wireshark.m4
> > +++ b/m4/virt-wireshark.m4
> > @@ -35,11 +35,20 @@ AC_DEFUN([LIBVIRT_CHECK_WIRESHARK],[
> >          dnl On some systems the plugindir variable may not be stored within pkg config.
> >          dnl Fall back to older style of constructing the plugin dir path.
> >          ws_plugindir="$libdir/wireshark/plugins/$ws_modversion"
> > -        ws_prefix="$prefix"
> > +        dnl We have no idea what the contents of $libdir look like, so we'll
> > +        dnl have to play a bit of a guessing game: let's try stripping off
> > +        dnl a bunch of likels prefixed and pick the first one that matches.
> > +        dnl Even if none does, we'll still have one last shot later
> > +        for try in "$prefix" "$exec_prefix" '${prefix}' '${exec_prefix}'; do
> > +          if test "x${ws_plugindir#$try}" != "x$ws_plugindir"; then
> > +            ws_prefix="$try"
> > +            break
> > +          fi
> > +        done
> >        fi
> >        if test "x$ws_prefix" = "x" ; then
> > -        dnl If the wireshark prefix cannot be retrieved from pkg-config,
> > -        dnl /usr is our best bet
> > +        dnl If the wireshark prefix cannot be retrieved from pkg-config
> > +        dnl or otherwise guessed, /usr is our best bet
> >          ws_prefix="/usr"
> >        fi
> >        dnl Replace the wireshark prefix with our own.
> 
> I am under the impression that it will be pretty hard to build a
> functioning solution for a plugindir-less wireshark.pc file other than
> for the purpose to fix the RPM build (and don't break make distcheck).
> 
> My first idea was to start off using the libdir value from wireshark,
> see
> https://www.redhat.com/archives/libvir-list/2016-October/msg01186.html
> (the wireshark.pc versions I've seen all have it set, as well as the
> prefix). This would cover the case where libdir[wireshark] !=
> libdir[libvirt].
> 
> But both your and my approach will only be correct if the [exec_]prefix
> of both libvirt and wireshark match, which will not be the case for
> non-RPM builds for the default configuration (exec_prefix=/usr/local) or
> the less usual but valid /opt/$package naming scheme.
> 
> Plus libdir has to be the same in both packages anyway in order to not
> break the RPM build (unless you want to tweak the spec file). I'd
> suggest to stick to your original version (and rely on the last shot as
> you put it): the general case is really hard to fix properly.

Of course the only way for the plugin to be loaded by Wireshark
is to install it in the directory Wireshark will load plugins
for :)

But, as far as libvirt is concerned, it's also completely okay
to install everything, including the plugin, under eg.
/usr/local regardless of the fact that Wireshark will look for
plugins in a sub-directory of /usr/lib. It would actually be a
bug if libvirt was compiled with prefix=/usr/local and
installed *anything* outside of /usr/local, unless the user
provides a very specific override.

We can't stick to the previous version because one very common
use case is broken with it: passing only prefix to configure
and relying on the automatically derived values for everything
else.

I've come up with a hybrid approach that incorporates some of
your suggested changes with the ones that we've come up with
independently, and AFAICT handles all reasonable use cases
correctly. I'll post it shortly.

Hope you don't mind my sticking with my own commits, it's just
that the fact that I'm changing a single thing per commit
makes review easier than lumping three changes together :)

-- 
Andrea Bolognani / Red Hat / Virtualization