I went through and checked each of these, and I think most of them should stay. The only ones that should be reverted are:

• citrix-workspace
• netbox
• plik

These 3 use callPackage within the file, so those derivations were already overridable, and using callPackages to pull them in means that override gets replaced with the wrong one that doesn't include all the arguments they use.

All of the others don't use callPackage inside the file for individual packages, instead declaring all dependencies as arguments for that file and building the packages within there. So they should keep using callPackages.

I'll open another PR that just reverts those.

I guess this has something to do with how the package set is actually called, so we have to evaluate the use of callPackages case by case. Let's revert it as a whole for now.

These 3 use callPackage within the file, so those derivations were already overridable, and using callPackages to pull them in means that override gets replaced with the wrong one that doesn't include all the arguments they use.

I think we should instead formalize how to construct these package sets.

Okay, that makes sense. I won't make any changes in that case.

Why did you revert everything? Someone already dug up which packages would need this removed and which don't and where my oversight was im the initial change.

Also one hour is not enough time to react. I would have created a fix for this now which wouldn't have broken other uses.

Now I must create a PR with everything except the Citrix, netbox and plik or otherwise my config won't evaluate and I cannot fix it in my config....

Do you have more details about the use case for callPackages? Maybe there's a way both use cases can be supported.

I think it always needs to be used when callPackage isn't used in an attrSet and is is inherited. After I found the third package which didn't use this correct, I just converted all of them at once in the knowledge that it would just work and that ofborg would complain if it wouldn't.

Can you please take a look at #282015 before nixos-unstable advances? Thanks!