Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> What about uses of guix-daemon on other distros?  Perhaps we assume tar
> and gzip are already on PATH?

That’s my guess.  And if those other weird distros don’t have ‘tar’ and
‘gzip’ in “/usr/bin”, I’m sure they’re plenty accustomed to liberally
patching their packages.  ;)

> I’d feel more comfortable with a solution at the package level.  In the
> ‘guix’ package, or perhaps in a Makefile.am, we could hard-code absolute
> file names of tar and gzip in (guix scripts perform-download) and set
> PATH from there.  We’d need to do the same in (guix self) though.
>
> Alternatively, we could change (guix swh) to use Guile-Zlib and the tar
> implementation of Gash-Utils or that of Disarchive.
>
> WDYT?

I’ve attached a new patch that mixes those two suggestions but gets the
first one a little wrong.  It uses the absolute path for ‘tar’, but uses
Guile-zlib for decompression.

I honestly don’t have a strong opinion about when and where to set
‘$PATH’ vs. using a configured, absolute path.  My original patch
assumed that it’s the user’s job to make sure that ‘tar’ and ‘gzip’ are
available to Guix at runtime.  This patch assumes that that linkage
happens at configure time.  The main benefit I could see to setting
‘$PATH’ in ‘(guix scripts perform-download)’ is that we could add our
‘tar’ and ‘gzip’ as a suffix.  This makes it work while allowing users
to choose whatever ‘tar’ and ‘gzip’ they prefer.  The downside is that
whenever we use ‘(guix swh)’ have to remember to make sure that ‘tar’
and ‘gzip’ are available.

Basically, I can to change this to do the setup in ‘perform-download’,
but I really want to understand why.

Thanks!