File-roller's fr-command-*.c files execute compression utilities based on a
predefined name, and relying on the path.  This is a good default, since
people building from sources manually (and knowing well their system, i.e.,
what's PATH and how is it set) will get good results.

However, there are situations when it's desirable to change these values
when building file-roller.  Consider a package system (concretely, pkgsrc)
and NetBSD.  The default system tar utility is not GNU tar; due to the
actual sources, file-roller will pick up this one and behave incorrectly,
since it requires GNU tar.  What we currently do in the pkgsrc package is
to depends on GNU tar and then modify file-roller to explicitly use it, by
changing the "tar" string in fr-command-tar.c to point to where GNU tar is
installed.  (This is not very scalable and will force us to rebuild our
patches on every file-roller update.)  Similar situations can be found in
all other compression methods.

What I propose is to modify file-roller's configure script to recognize
several options to explicitly specify where programs can be found
(defaulting to the actual values, to not break anything).  The attached
patch in this bug report defines multiple --with-{program}-path arguments
in the configure.in script (one for each compression/decompression
utility), and later converts these values to C defines, used by sources, in
src/Makefile.am.  If an argument is not specified, its default value will
be the actual name used in the sources, relying on the path.  (There is one
exception, though, where I renamed gtar to tar, as in almost all systems.)

If you don't like this solution, because you think it's an overkill of
options, I can come up with something based on #ifdef's, where the user
could set values by setting them in CPPFLAGS.  Although, I find patching
configure cleaner, since it is more visible and usable by less experienced
users.

Note that these options will be mostly used by packaging systems, to
hardcode paths to utilities because they know beforehand where they are and
they know those specific versions are compatible with file-roller.