-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
Should cabal.mkDerivation reset modification times? #1280
Comments
Catching this problem in the generic builder feels like overkill to me. I would just report the issue upstream. If upstream fixes the tarball, everything is fine. If upstream turns out to be unresponsive, then I'd rather add an Arguably, it might be a good idea to pass the |
Ok. I've already reported it upstream. I did mention it in |
In regards to |
Unfortunately, we use many native tools on platforms like FreeBSD and Related: #874 |
Is there anything more to do on this? It seems like the few cases where this is an issue are best addressed by fixing it upstream. |
I still think |
If we do this, then broken release tarballs go undetected. I consider it a feature that these builds fail, not a bug. |
There's your answer then @shlevy :) |
This is a bit of a stab in the dark, so bear with me. I'm trying to install
indexed-free
at the moment, which appears to incorrectly packed by the maintainer. When I try andnix-build
it, I see the following output:However, if I
jailbreak = true
on this expression, that has the effect of changing the modification timestamp onindexed-free.cabal
and the build succeeds. I believe the above happens because the modification timestamp is in the future, so Cabal tries to automatically reconfigure at every step - including after we have setGHC_PACKAGE_PATH
.Should we change our builder to
touch
files to avoid this problem?The text was updated successfully, but these errors were encountered: