I wonder whether we should have a setup hook for gnutar that exports these options by default using TAR_OPTIONS.

TAR_OPTIONS="--mtime="@$SOURCE_DATE_EPOCH" --sort=name ${TAR_OPTIONS:-}"

I wonder whether we should have a setup hook for gnutar that exports these options by default using TAR_OPTIONS.

TAR_OPTIONS="--mtime="@$SOURCE_DATE_EPOCH" --sort=name ${TAR_OPTIONS:-}"

I think that might be a good idea if we encounter this a few more times on the r13y journey. Right now it is the only place we've seen that being required?

I think that might be a good idea if we encounter this a few more times on the r13y journey. Right now it is the only place we've seen that being required?

Using grep shows we use it for

• NixOS system tarball
• bazel packages
• docker tools
• kernel headers
• bootstrap tools

We don't tar so often, however, if I would use tar in a nix-build, I would want it to be reproducible.

I think that might be a good idea if we encounter this a few more times on the r13y journey. Right now it is the only place we've seen that being required?

Using grep shows we use it for

* NixOS system tarball

* bazel packages

* docker tools

* kernel headers

* bootstrap tools

We don't tar so often, however, if I would use tar in a nix-build, I would want it to be reproducible.

Ok, then that might be warranted. :)

Note however that adding the hook to gnutar will make it work like this as well when using nix-shell -p. Now, I don't think that is a problem because nix-shell is meant to be reproducing a build environment, but given so many people (ab)use nix-shell with the idea they can just get the tools they want, and ignore they're in a build environment, it could be problematic.

Note however that adding the hook to gnutar will make it work like this as well when using nix-shell -p. Now, I don't think that is a problem because nix-shell is meant to be reproducing a build environment, but given so many people (ab)use nix-shell with the idea they can just get the tools they want, and ignore they're in a build environment, it could be problematic.

You may call it "abuse", but this is definitely an extremely common usage of nix-shell and is prominently featured in the documentation. And we don't have a good replacement either.

And we don't have a good replacement either.

Well this is what nix shell will be for, right?

You may call it "abuse", but this is definitely an extremely common usage of nix-shell and is prominently featured in the documentation. And we don't have a good replacement either.

I am aware of that, and it is why I mentioned it. It is also the reason why issues related to hooks are opened; many don't seem to get that nix-shell gives the build environment. Documenting this prominently on the website in my opinion shows how big the problem is and makes it only worse. Too much pragmatism there. Unfortunately, we need to consider it.

And we don't have a good replacement either.

Well this is what nix shell will be for, right?

Which is why I suppose we would have to wait for the release of nix before we can introduce the hook.

Is there any downside to sorting archives by name by default? Do people rely on file sorting in archives? That sounds a bit like a hack.

Is there any downside to sorting archives by name by default? Do people rely on file sorting in archives? That sounds a bit like a hack.

I agree I don't expect people to rely on the ordering. I'm less sure about the mtime, though.

SOURCE_DATE_EPOCH is not set in the nix-shell environment so we could rely on that to conditionally activate both flags.

SOURCE_DATE_EPOCH is not set in the nix-shell environment so we could rely on that to conditionally activate both flags.

Then IN_NIX_SHELL is better I think. Ugly though. With these kind of hacks it makes more sense to make the whole setuphook machinery optional when IN_NIX_SHELL, which of course defies the point when you want a build environment.

I like the idea of adding a gnutar setup hook, but since it appears it's not trivial to decide what that should look like exactly, perhaps we should merge this as-is and create a new issue for the more general solution?

Hey, don't know what this PR is all about, but setuptools needs an update: https://github.com/pypa/setuptools/releases

python.pkg.pikepdf is currently broken and it can also be updated, but that requires wheel >= 0.35 which is not yet updated (see #105974 ). setuptools>=50 is also required for pikepdf.

I've updated it anyway with sed -i to setup.py in #105977 .