tar references gzip out of the path.

[kevincox]

If gzip isn't in your path tar -czf ... fails with "gzip: Cannot exec: No such file or directory"

[matthewbauer]

gzip should be in "stdenv" I think. Are you able to build stdenv?

[kevincox]

It is in stdenv, but sometimes if you build your own path it doesn't include stdenv. If the hope that it uses the gzip from stdenv on purpose it should probably reference /run/current-system/sw/bin explicitly although I guess that would break it on non-NixOS systems.

[peti]

I think it's perfectly fine for tar to have optional dependencies on various compressors to be found at run-time. That's not a bug, IMHO.

[kamilchm]

I found it to be inconsistent for mesos package.
It optionally need to extract different archives. I patched it some time ago to use full nix path for tar #17294
But now if it tries to extract tar.gz it needs gzip which can't be found in its path.
@peti how should I provide both tar and gzip to mesos-slave service?

[peti]

@kamilchm, just put both tar and gzip into $PATH. I'm not sure whether I see the problem?

[kamilchm]

There are lot of substituteInPlace in https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/cluster/mesos/default.nix for programs like scp, gzip, tar, unzip ....
Do you suggest to replace all of substituteInPlace in sources and provide all referenced programs with $PATH?

[peti]

Do you suggest to replace all of substituteInPlace in sources and provide all referenced programs with $PATH?

I believe that both approaches have their merits. A hard-coded path is fine, too. It doesn't seem like anyone would gain anything by replacing those path by reliance on $PATH instead.