Revert "nv-codec-headers: recreate under by-name"

[flokli]

This reverts commit 01f7c8a.

It broke NixOS config evaluation, as in
#324199 (comment).

Description of changes

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.

[Aleksanaa]

Did you have a pkgs.sources sitting somewhere in your config? While this does seem like it could cause a problem, we haven't encountered it yet (in Nixpkgs)?

[flokli]

Did you have a pkgs.sources sitting somewhere in your config? While this does seem like it could cause a problem, we haven't encountered it yet (in Nixpkgs)?

I have a sources in my NixOS config, yes (and use Niv to pin dependencies), I define it in an overlay like this:

  sources = import ./sources.nix { inherit (super) system; };

… and use sources. in various places in my NixOS configuration.

[Aleksanaa]

Still don't get it, we even don't have any nv-codec matches in nixos modules?

[Aleksanaa]

Oh

[flokli]

Ah, it's because pkgs/by-name/nv/nv-codec-headers/package.nixdoes getcallPackage`'ed. Yeah, this is bad.

[Aleksanaa]

That should be ideal though, I guess that's where the "default version" comes from

[flokli]

I don't think this sources defaulting to ./sources.nixshould be an overridable argument.
Same for other bits to produce different variants (like majorVersion).

AFAIK, the only inputs should be packages defined in the package set, and if things get too fancy, they should live outside by-name, to avoid these sudden surprises.

[Aleksanaa]

So every time I tell people a joke, it becomes something serious (Remember dbus-broker, Huh)

[flokli]

(cc @infinisil )

[Aleksanaa]

I don't think this sources defaulting to ./sources.nixshould be an overridable argument. Same for other bits to produce different variants (like majorVersion).

AFAIK, the only inputs should be packages defined in the package set, and if things get too fancy, they should live outside by-name, to avoid these sudden surprises.

Agree, this is too non-trivial to put in by-name.

[Aleksanaa]

We have no rebuilds.

[flokli]

Alright, so let's merge this revert. I'll propose a PR updating pkgs/by-name/README.md, so we get this written down more clearly.

[TomaSajt]

I don' think the main issue is pkgs/by-name.
It's just callPackage being callPackage
You would have encountered the same issue in a package that's not in by-name, since you're supposed to call packages with callPackage anyways.

The fact that the package broke was because they also refactored the code.
The main issue was just having sources being present in the override-able argument list.
(Which, IMO, should have just be placed into the let in block, since you would probably only ever have to override the majorVersion anyways)

[AndersonTorres]

The main issue was just having sources being present in the override-able argument list.

This was intentional: the source list is treated as part of calling interface.