-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Purebred should recompile when binary changed under NixOS #255
Comments
We've contacted the maintainer of dyre. The project seems to be asleep unfortunately. Perhaps it could be handed over in order to get patches in. |
@frasertweedale perhaps we could also consider a patch in the NixOS package as a possible solution which is only nix specific? |
It is an option, and probably preferable to putting the workaround in purebred itself. And the patch can hopefully be upstreamed later. |
Hm.. I think this problem is not only related to NixOS. I made a new purebred build yesterday and after upgrading the executables mtime is basically the build time:
I think dyre has no chance of figuring out that the executable is newer in such a circumstance:
If the build time is really setting the mtime, there will always be a situation that the users config is newer than the built executable. |
Right, that's a package manager thing. Very clear reason to get this into dyre. |
I pulled down the RPM, unpacked it and checked again the
So my assumption that it was set to the 12 of January was wrong. For whatever reason that package did not seem to have gotten upgraded. Nevertheless... if my config is newer (for whatever reason.. I changed configuration) than the |
Is your feature request related to a problem? Please describe.
Unfortunately NixOS always sets the mtime to 1970. The dyre library unfortunately uses mtime in order to determine if the main executable has changed. So under NixOS we won't get any rebuilds if we for example ship an updated purebred unless the user himself removes the cached binary.
Describe the solution you'd like
Ideally, provide a way for dyre to use a different way to determine that the executable has changed. @frasertweedale and I had discussed this on #bfpg on IRC and we concluded that probably a better way to figure out if the executable had changed is by hashing it and saving the hash in a file next to the cached, compiled binary.
Describe alternatives you've considered
None
Additional context
We could use a temporary workaround, but I think this affects more applications shipping to NixOS using dyre. So an upstream change would be better.
The text was updated successfully, but these errors were encountered: