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
linuxHeaders: 5.5 -> 5.9.8 #103575
linuxHeaders: 5.5 -> 5.9.8 #103575
Conversation
This will not work, because the version can change without the hash. |
I intend for the hash to be updated when linuxPackages_latest is updated. For example, included in #100528 but for 5.10. |
But it could be made to work by comparing at build time (in an early phase of This way the build of the headers would fail, if the version attribute and the hash of the sources diverge, so when someone updates the branch of the latest kernel, and forgets to update the hash here, they will hopefully notice, because the build fails. |
It already does that and that is the point of using
|
Ah |
Please don't rely on hash mismatches. If an update is reverted without reverting the hash, then there will be no error message and the old tarball will be used. |
This would be the case with |
I don't think this change is a good idea: updates to If we couple the My preference would be to bump |
But do we often need to bump it across major versions? This uses the branch name, not the precise version. |
Ok, that's better. But it still means that the |
4665eab
to
bfaa9af
Compare
The point was to ensure that this package always is updated, but not worth it for delaying updates. |
Sorry, I completely lost track of this PR. |
Motivation for this change
https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F
To prevent excessive mass rebuilds linux_latest.meta.branch is used instead of linux_latest.version.
Things done
sandbox
innix.conf
on non-NixOS linux)