Skip to content
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

Open
romanofski opened this issue Feb 16, 2019 · 7 comments
Open

Purebred should recompile when binary changed under NixOS #255

romanofski opened this issue Feb 16, 2019 · 7 comments

Comments

@romanofski
Copy link
Member

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.

@romanofski romanofski added this to the Future Feature milestone Feb 16, 2019
@romanofski
Copy link
Member Author

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
Copy link
Member

@romanofski
Copy link
Member Author

@frasertweedale perhaps we could also consider a patch in the NixOS package as a possible solution which is only nix specific?

@frasertweedale
Copy link
Member

It is an option, and probably preferable to putting the workaround in purebred itself. And the patch can hopefully be upstreamed later.

@romanofski
Copy link
Member Author

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:

» sudo dnf install purebred
Last metadata expiration check: 0:36:22 ago on Tue 19 Feb 2019 09:30:18 AM AEST.
Dependencies resolved.
=============================================================================================================================================================
 Package                        Arch                         Version                                         Repository                                 Size
=============================================================================================================================================================
Installing:
 purebred                       x86_64                       0.1.0.0-0.20181201.fc29                         romanofski-purebred                       2.7 M

Transaction Summary
=============================================================================================================================================================
Install  1 Package

Total download size: 2.7 M
Installed size: 17 M
Is this ok [y/N]: y
Downloading Packages:
purebred-0.1.0.0-0.20181201.fc29.x86_64.rpm                                                                                  848 kB/s | 2.7 MB     00:03    
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                        847 kB/s | 2.7 MB     00:03     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                     1/1 
  Installing       : purebred-0.1.0.0-0.20181201.fc29.x86_64                                                                                             1/1 
  Running scriptlet: purebred-0.1.0.0-0.20181201.fc29.x86_64                                                                                             1/1 
  Verifying        : purebred-0.1.0.0-0.20181201.fc29.x86_64                                                                                             1/1 

Installed:
  purebred-0.1.0.0-0.20181201.fc29.x86_64                                                                                                                    

Complete!
dukat :: ~ » stat /usr/bin/purebred 
  File: /usr/bin/purebred
  Size: 17989112        Blocks: 35136      IO Block: 4096   regular file
Access: 2018-12-01 16:51:38.000000000 +1000
Modify: 2018-12-01 16:51:38.000000000 +1000
Change: 2019-02-19 10:06:47.846491545 +1000
 Birth: -

I think dyre has no chance of figuring out that the executable is newer in such a circumstance:

stat ~/.cache/purebred/purebred-linux-x86_64
  File: /home/rjoost/.cache/purebred/purebred-linux-x86_64
  Size: 7454680         Blocks: 14556      IO Block: 1024   regular file
Access: 2019-02-19 10:01:23.000000000 +1000
Modify: 2019-02-15 15:33:19.000000000 +1000
Change: 2019-02-15 15:33:19.000000000 +1000
 Birth: -

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.

@frasertweedale
Copy link
Member

Right, that's a package manager thing. Very clear reason to get this into dyre.

@romanofski
Copy link
Member Author

I pulled down the RPM, unpacked it and checked again the mtime:

stat purebred
  File: purebred
  Size: 15072           Blocks: 32         IO Block: 4096   regular file
Access: 2019-02-18 16:54:40.000000000 +1000
Modify: 2019-02-18 16:54:40.000000000 +1000
Change: 2019-02-19 10:27:49.836512702 +1000
 Birth: -

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 dnf update can ship the binary it will not recompile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants