sunxi-tools: 20171130 -> 20181113 #51007
Conversation
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: sunxi-tools Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: sunxi-tools Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: sunxi-tools Partial log (click to expand)
|
| @@ -1,13 +1,13 @@ | |||
| { stdenv, fetchFromGitHub, pkgconfig, libusb, zlib }: | |||
|
|
|||
| stdenv.mkDerivation { | |||
| name = "sunxi-tools-20171130"; | |||
| name = "sunxi-tools-20181113"; | |||
There was a problem hiding this comment.
Should be sunxi-tools-unstable-2018-11-13.
There was a problem hiding this comment.
I know that fact, but because of how nix-env handles version comparisons, I believe unstable-yyyy-mm-dd is always seen as older than yyyymmdd.
nix-repl> builtins.compareVersions "20181113" "20171234"
1
nix-repl> builtins.compareVersions "unstable-2018-11-13" "20171234"
-1
builtins.compareVersionss1s2
Compare two strings representing versions and return -1 if versions1is older than versions2, 0 if they are the same, and 1 ifs1is newer thans2. The version comparison algorithm is the same as the one used bynix-env -u.
The idea here is to ensure end-users' software is upgraded. Not sure if there's a bigger issue to be tackled with regards to that existing discrepancy inside Nixpkgs.
There was a problem hiding this comment.
Indeed, and in fact this sounds very problematic. More so, I don't think a lot of nix devs are interested in ensuring nix-env works properly, so 👍 for bringing this to my attention.
There was a problem hiding this comment.
But unstable is going to be part of the pkg name, not the version part:
nix-repl> name = "pkg-unstable-20180101"
nix-repl> builtins.parseDrvName name
{ name = "pkg-unstable"; version = "20180101"; }It will "break" pkg upgrade not because of versions comparison but because of the name change.
I agree this "rule" of the manual comes from a good idea but raises some practical questions.
I later read @fpletz mentioning the idea of this rule was to allow maintaining two versions of a package (unstable and normal/stable). Which is sound too. But unclear in the manual.
For case like this when we fetch a non-release commit, maybe the unstable tag should come at the end of the version part as to not break version comparison logic?
nix-repl> name = "pkg-20180101-unstable"
nix-repl> builtins.parseDrvName name
{ name = "pkg"; version = "20180101-unstable"; }
nix-repl> builtins.compareVersions "2018-01-01-unstable" "2017-10-01"
1There was a problem hiding this comment.
Oh! misremembered that detail about why it would fail. I was sure the version attribute would have been in use there. Though I knew for sure it would fail. Thanks for the clarification and confirmation.
There was a problem hiding this comment.
Adding -unstable at the end of the version number is not good either because we still have a version comparison issue when a package comes back to a stable release number. We had the case recently in #51087.
Anyway, that's a broader issue. Let's not stall this update for this.
Motivation for this change
The update is necessary to flash the SPI NOR flash available on some AllWinner devices.
The revision chosen is the current tip of
master.Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)This was verified as working, as the instructions on the NixOS wiki were followed using that build.