srcOnly: make the -source suffix optional

[thecaralice]

Description of changes

srcOnly has a use as a trivial builder - cases when you just want to apply a patch to some derivation for example. However, it does not give the user full control of its name, since it adds a -source to whatever name the user provides. This PR addresses that by adding a noSuffix argument to srcOnly. The argument is only read when provided directly and not drvAttrs (should that be changed? Let me know).

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

[Mic92]

I don't quite get the use case, what advantage does it have to change the suffix to something else? Aesthetics?

[thecaralice]

One use case is having a derivation of form ${pname}-${version} without the -source suffix. Maybe it is also the only one? Now that I think of it, it might be better to make the argument a boolean instead.

[Mic92]

Okay but what do you do with the source code afterwards. Do you not put pass it on to a different derivation to perform some other build?

[thecaralice]

Sometimes I don't. I can't remember any exact details but I think I had a case when I just needed to patch something without copying everything in the installPhase manually.

[philiptaron]

This is an oddly shaped derivation helper prior to this PR.

• attrset name presence or absence determines semantics
• attrset names not used are dropped on the floor
• drvAttrs if specified are overridden by the function
• installPhase does not run hooks
• xor behavior with name and pname/version

I'm on mobile reviewing this, so I haven't searched through nixpkgs, but I'm really struggling to see the use case for which this helper was created.

[thecaralice]

Yeah, I found it weird as well, although it does solve my issues. As I see it, it tries to do two different things:

1. Extract the source of a certain derivation
2. Trivially build a source by fetching, unpacking and applying patches, but not actually building anything

The first one is the reason of the drvAttrs magic, not running install hooks (the original hooks are not fit for the new installPhase) and dropping most attrs.

Should I do a heavier refactoring?

[philiptaron]

Should I do a heavier refactoring?

I don't know 🤷🏻‍♂️. All I know is that this helper is too weird for me to review changes to, and after reading it, I'll avoid using it in nixpkgs.