We need more defined guidelines for package inclusion

Sounds like we’ve found out where I could put this information :+1:

1 Like

Just give a hard number here: nixpkgs currently contains 1663 derivations that have meta attribute but no maintainer (noMaintainers · GitHub)

I’m curious to know how that list was generated, because these two definitely don’t belong:

pkgs/build-support/rust/build-rust-crate/default.nix:89
pkgs/build-support/trivial-builders.nix:7

I look at all derivations in nixpkgs that have a meta attribute but not maintainers field. That contains everything including auto generated files for nodejs etc, and also some false positives such as some builders. That 1663 is an upper bound but then even you subtract the entries that don’t belong there in reality: it won’t get that much shorter.

(missing_maintainers.nix · GitHub, I did the same last year to figure out derivations with missing licences).

3 Likes

Today I realized that I really don’t want to include binary packages.
And the prime offender are “an electron blob” apps. So much so I’ve avoided PRs including them.
And this is no :tea: to electron apps, my first package contribution to nixpkgs happened to be one of them. They’re just problematic. We have to make special backport exceptions because they depend on web services. It’s really quite a mess and I understand why Fedora has a restriction for this. That and multiple kernel flavors.

And this is no :tea: to electron apps, my first package contribution to nixpkgs happened to be one of them. They’re just problematic. We have to make special backport exceptions because they depend on web services.

I think there are Electron apps that do not, and there are non-Electron apps (like command-line GitHub clients) that do.

And NodeJS packages might not be literally binary but when bundling a huge hard-to-diff lockfile they are not quite annoying.