Comment by baobun
20 hours ago
The issues with nixpkgs stem from that it is a monorepo for all packages and doubling as an index.
The issues are only fundamental with that architecture. Using a separate repo for each package, like the Arch User Repos, does not have the same problems.
Nixpkgs certainly could be architected like that and submodules would be a graceful migration path. I'm not aware of discussion of this but guess that what's preventing it might be that github.com tooling makes it very painful to manage thousands of repos for a single project.
So I think it can be a lesson not to that using git as a database is bad but that using github.com as a database is. PRs as database transactions is clunky and GitHub Actions isn't really ACID.
It's not a monorepo though? It's a package index, it has the package metadata. It doesn't have the actual source code of the projects themselves.
Point being it carries both the index (versions/pointers) and full metadata + build instructions for all packages in single repo.
The index could be split from the build and the package build defs could live in independent repos (like go or aur).
It would probably take some change to nix itself to make that work and some nontrivial work on tooling to make the devex decent.
But I don't think the friction with nixpkgs should be seen as damning for backing a package registry with git in general.