minecraft: mark broken

[tomberek]

Description of changes

The minecraft launcher will fail for new versions. This results in a hard-to-understand error. Either we mark the package as broken (yes, it does work when launching old versions) or provide a warning.

Fixes: #179323

Things done

Added a warning..... asking for feedback if marking broken = true; would just be better.

• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 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.

[TLATER]

I think the warning is better than marking it broken, if only because this message shows the alternatives.

[sudoforge]

I think the warning is better than marking it broken, if only because this message shows the alternatives.

i believe that the message should be shown on stderr prior to true being evaluated:

trace e1 e2

Evaluate e1 and print its abstract syntax representation on standard error. Then return e2. This function is useful for debugging.

https://nixos.org/manual/nix/stable/language/builtins#builtins-trace

---

that said, it looks like emitting something to stderr causes the ofborg-eval step to fail. perhaps it's not possible to use builtins.trace here after all.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/93

[doronbehar]

I have a bottom line question (haven't read all prior discussions): Is the derivation actually usable? For anyone?

[sudoforge]

I have a bottom line question (haven't read all prior discussions): Is the derivation actually usable? For anyone?

no, it is broken.

[doronbehar]

Then why not simply broken = true?

[sudoforge]

Then why not simply broken = true?

that's described by the author of the change, in one of the four comments you decided to skip:

#299645 (comment)

[tomberek]

I'm willing to go in either direction. Just let me know.

[doronbehar]

This is a broad issue in Nixpkgs - that we lack a robust way to describe why packages are broken, besides writing a comment above the broken = true; line. I suggest to not insist on inventing a solution to this issue here, and skip to the common approach of simply broken = true; along with a comment.

[TLATER]

I have a bottom line question (haven't read all prior discussions): Is the derivation actually usable? For anyone?

no, it is broken.

It actually is usable, so long as you don't try to play relatively recent minecraft versions with it. Older versions still work because they don't bundle natively compiled code.

This is why I was hesitant to mark it broken in the first place. But other than that, broken + comment is probably fine for now, and we should invent a better solution for these things.

[tomberek]

updated to accommodate the consensus that marking "broken" is better