I don’t know, whether it has been discussed in the past, but it seems like tor-browser-bundle-bin always fails to build whenever a new version comes out. Apparently, that’s because upstream does not keep old versions on their mirrors and caching is disabled in nixpkgs for this package. We cannot do anything about the former, but I have some questions about the latter.
First of all, what are the reasons behind this decision? Are they documented somewhere to keep the community informed? If we need to have package for tor browser with caching disabled, can we have another one with it enabled?
Personally I don’t include Tor browser in my config because it would make it too fragile.
The commit doesn’t say why disabling remote builds or substitutions is necessary. It does say this package’s files in $HOME will still have a few messy references to /nix/store. The only thing that comes to mind quickly is that if the package is cached then the store paths will be the same across any machine using the regular Nix cache which might give the illusion that the package works better than it ‘should’?
Perhaps it’s just a security concern to have this package build anywhere but locally?
As I recall, disabling Hydra caching had nothing to do with security (per se) or the Nix store path capture issue. It was primarily to reduce load on Hydra.
Failing the build when a new version is released could be considered a security feature because it prevents you from using
an outdated version (I guess that is upstream’s rationale for removing older versions to begin with), but obviously it is vexing for end-users.
Seeing as this is a recurring problem, I suppose caching should be re-enabled if that’s what users prefer. The ideal solution would be to always keep the expression up-to-date across unstable and release branches, but I think all evidence thus far is that this is just not going to happen without tooling support.
For “binary” packages it would be much more efficient to cache the src instead of the result. It’s not just about “build” work, but also all the CDN expenses afterwards added on every rebuild.
We already do have a mechanism that scoops tarballs from (current stable?) nixpkgs and uploads them on tarballs.nixos.org, and that fixed-hash-addressed place is then tried by fetchurl before the normal locations. Unfortunately I can’t see an easy way to find why these tarballs aren’t there now.
This is only theoretical right? tor-browser-bundle ist not very big (only a small 108MB) and should not make a significant difference for hydra or the cache.
My post related my recollection of the main motivation at that time, not the only motivation.
To the point: it is true that, in isolation, disabling caching of TBB does not make a difference to overall bandwidth usage. The same can be said for many packages that disable Hydra caching. The aggregate effect of avoiding unnecessary cache usage across NixPkgs can be large, however.
Instead of setting this for individual packages we should think about a general way like maybe relying on lib.sourceTypes.binaryNativeCode and preferLocalBuild and dontSubstitute but we want to cache at least the source on hydra and for that hydraPlatform cannot be an empty list.