-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
fetchurl: disallow specifying both sha256
and hash
#182953
Conversation
A full check would be more complicated to write - and more importantly - probably also more expensive. Motivation: eval-time catch for errors like in commit 8198636.
So, OfBorg doesn't show removed packages, but if you run the rebuild-amount script in reverse, you can see which packages get thrown by this. It's more than I expected, hundreds just from I believe this needs community feedback, around disallowing this, using |
Other unresolved packages:
|
Let's stop using src.override. I see no advantage.
9c066c0
to
ccf609a
Compare
Completed the changes to home-assistant to get rid of these kinds of overrides. |
/cc @SuperSandro2000 as the other author of |
# Many other combinations don't make sense, but this is the most common one: | ||
if hash != "" && sha256 != "" then throw "multiple hashes passed to fetchurl" else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Many other combinations don't make sense, but this is the most common one: | |
if hash != "" && sha256 != "" then throw "multiple hashes passed to fetchurl" else | |
if hash != "" && sha1 != "" && sha256 != "" && sha512 != "" then throw "multiple hashes passed to fetchurl" else |
might as well. Also what about we drop sha1 like md5?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not how you check for existance of more than one hash though. And the proposed solution is at least pareto optimal.
❯ rg "sha256 =" -l | wc -l
19006
❯ rg "sha512 =" -l | wc -l
155
❯ rg "sha1 =" -l | wc -l
55
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You suggest wrong conditions. (uh, comment race, GitHub didn't update the thread for me)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will only fail on all of them present, so it would have to be a hash & sha1 || hash & sha256 || hash & sha512 || sha1 & sha256....
or some kind of (count-non-empty-in [hash sha1 sha256 sha512]) > 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before outright dropping the support I'd go through some time when it just prints an annoying warning. And I haven't checked the current usage in nixpkgs and tools. Anyway, that's way bigger than this PR and there's an issue already: #77238
Instead of backing off overriding sources, could we maybe fix the override function so that it produces the correct behavior? For example, setting |
AFAIK it's general |
Also, what if the original derivation switches the fetchers. We commonly use many: fetchurl, fetchFromGitHub, fetchPypi... so after switching your override won't make really sense anymore. Overall I couldn't find motivation why to use |
Alternatively we could converge on a single |
Possibly, but that sounds orders of magnitude more complex and far way, in comparison to this PR. EDIT: I'm not trying to claim that something like this PR will be a perfect final solution. |
Yeah, we could have
That’s just the pain we have to deal with when using any overrides. We are hoping such changes are relatively rare. The point is that with #119942, the best case scenario allows you to just do |
It would be simpler to just move |
ffe156f
to
ad8d5e0
Compare
Well, perhaps. This seemed simple and foolproof. I just wanted to get some OK solution so this PR can get merged without dropping packages. EDIT: meaning that later improvements are welcome – and people will get the I now checked eval against master and found no dropped packages anymore. |
Not really a fan of the last 3 commits but I also don't know a better solution than just using hash all the time. |
A full check would be more complicated to write -
and more importantly - probably also more expensive.
Motivation: eval-time catch for errors like in commit 8198636.