-
-
Notifications
You must be signed in to change notification settings - Fork 14k
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
arm-trusted-firmware: remove version parameter #185004
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ofborg
bot
added
10.rebuild-linux: 1-10
10.rebuild-linux: 1
and removed
10.rebuild-linux: 0
labels
Aug 4, 2022
SuperSandro2000
approved these changes
Aug 4, 2022
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.
squash merge
ghost
requested a review
from SuperSandro2000
August 4, 2022 22:06
This comment was marked as outdated.
This comment was marked as outdated.
ofborg
bot
added
10.rebuild-linux: 0
and removed
10.rebuild-linux: 1
10.rebuild-linux: 1-10
labels
Aug 5, 2022
ghost
marked this pull request as draft
August 6, 2022 20:33
ghost
marked this pull request as ready for review
August 6, 2022 20:33
ghost
changed the title
arm-trusted-firmware: prevent dangerous version mixups
arm-trusted-firmware: remove version parameter
Aug 7, 2022
ghost
requested a review
from SuperSandro2000
August 7, 2022 02:04
ghost
requested a review
from SuperSandro2000
August 7, 2022 22:36
Squashed. |
The arm-trusted-firmware/default.nix expression exposes `buildArmTrustedFirmware` and its `version?"2.7"` field to `top-level/all-packages.nix`. Unfortunately it doesn't work. Changing the version field doesn't change what version of the ATF source code is used. Attempting to "lock" an installation to a specific version by overriding this field (e.g. version="2.7") won't work either; when nixpkgs bumps the version to 2.8 the user will end up building the 2.8 source code but the resulting expression will be labeled misleadingly in the store: ``` /nix/store/eeee...-arm-trusted-firmware-2.7/ ``` **using the 2.8 source code**. So not only does `version` not lock the version, it will actually *conceal* the fact that the underlying source code has been upgraded! Let's just remove the `version` field. It doesn't work and never did. #185004 (comment) Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
The arm-trusted-firmware/default.nix expression exposes
buildArmTrustedFirmware
and itsversion?"2.7"
field totop-level/all-packages.nix
.` Unfortunately it doesn't work. Changing the version field doesn't change what version of the ATF source code is used. Attempting to "lock" an installation to a specific version by overriding this field (e.g. version="2.7") won't work either; when nixpkgs bumps the version to 2.8 the user will endup building the 2.8 source code but the resulting expression will be labeled misleadingly in the store:
using the 2.8 source code. So not only does
version
not lockthe version, it will actually conceal the fact that the underlying
source code has been upgraded!
Let's just remove the
version
field. It doesn't work and never did.Things done
x86_64-linux
)./result/bin/
)