Remove uses of gzip that might capture build time #21306
Conversation
gzip is originally called as 'gzip -9 -c' This is a port of NixOS@a8e7ddd Note that it does not seem to make a difference to `nix-build --check`.
Note that it does not seem to make a difference to `nix-build --check`.
Note that it does not seem to make a difference to `nix-build --check`.
|
Is this solving an issue we have? If it's really an issue it seems fragile to depend on patching all the invocation of gzip, it might be easier to patch gzip to remove that feature and provide that gzip flavor at build time. |
|
Some invocations of gzip do seem to cause non-reproducible outputs, so yes, in some cases it does solve a problem. I also thought it might make more sense to do this some other way ... |
|
We could instead set the |
|
Unfortunately, the gzip manpage says about |
|
Unfortunately, the gzip manpage says about `GZIP` that "This feature will be removed in a future release of gzip".
Is a «gzipWrapper» that is just `${gzip}/bin/gzip -n "$@"` a good replacement for
gzip as a build dependency then?
|
|
@7c6f434c the determinism PR contains a fake date utility, I've been tinkering with wrappers along the same vein, so I think that'd be a good route to go (I was a little surprised the current PR was merged, tbh :)). That said, the question is really if somebody will commit to writing, testing, and getting a better solution merged ... If we have to wait 2 more years for a perfect solution to materialize I'd rather go ahead with patching stuff. It also occurs to me that many uses of gzip are to compress man pages, which I expect would otherwise be handled properly by the compress-manpages phase hook ... |
More work on extracting non-controversial stuff from #2281
No idea if this is worthwhile but for completeness ... if this is something we want I have a few more queued up (some that also fix determinism issues; none of the ones I've included in the initial batch seem make a difference ...)