kryptor: .NET 6 -> 8

[gepbird]

Tracking: #326335

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[gepbird]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 363629

---

x86_64-linux

✅ 1 package built:

• kryptor

[arthsmn]

LGTM

[gepbird]

cc @corngood @emilazy (#358533)

[getchoo]

@ofborg build kryptor kryptor.passthru.tests

[corngood]

If you like, you could use "$UPDATE_NIX_ATTR_PATH" here, and on the next line.

Some packages even do something like:

attr="${UPDATE_NIX_ATTR_PATH:-kryptor}"

to keep the script working when called directly.

It's only helpful if someone makes an overridden version of the package at another attribute path, so it's up to you whether you think it's worth it.

[gepbird]

I think it's cleaner as it is now, even if it won't work for overridden packages, thanks for the suggestion though.

Bit off topic but are there any plans for passthru.updateScript = nix-update-script { } supporting dotnet and updating deps.nix?
It works with for example pnpm packages, where it updates the hash inside pnpmDeps = pnpm.fetchDeps { hash = "..."; ... }

Also currently it's nice that each nuget package from deps.nix (and soon deps.json) is a seperate derivation and can be built independently, but regarding to #327064, what do you think about something like nugetDeps = dotnet_sdk.fetchNugetDeps { hash = "..."; ... };? A similar movement is also happening for rust packages.

[corngood]

what do you think about something like nugetDeps = dotnet_sdk.fetchNugetDeps { hash = "..."; ... };?

The problem is that restore isn't deterministic. There's no lock-file in most packages, and even if there was, the dotnet lockfile mechanism has some problems.

It's a good idea though. Maybe we'll get there eventually.

[nix-backports]

Successfully created backport PR for release-24.11:

• [Backport release-24.11] kryptor: .NET 6 -> 8 #363917