Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Tracking] Packages too important to be orphaned #327779

Open
AndersonTorres opened this issue Jul 17, 2024 · 6 comments
Open

[Tracking] Packages too important to be orphaned #327779

AndersonTorres opened this issue Jul 17, 2024 · 6 comments
Labels
5. scope: tracking Long-lived issue tracking long-term fixes or multiple sub-problems

Comments

@AndersonTorres
Copy link
Member

AndersonTorres commented Jul 17, 2024

Issue description

As the issue says, there are too many packages in Nixpkgs that are being maintained by no one [*] and are too important, in the sense that nothing can be done without them.
Things like GNU Make, some networking libraries etc.

[*] "no one" here has two more or less equivalent meanings:

  • "absolutely no one", an empty maintainers list; and
  • no active maintainer - there are maintainers but all were retired

Related Links:

NixOS/rfcs#180
NixOS/rfcs#127

#290642

Steps to reproduce

  1. Some magic command to seek for empty maintainers list:
$> grep -rP "maintainers\s*=\s*(with\s*(lib.)?maintainers;)?\s*\[\s*\]\s*;" $(pwd)

(thanks Sigmanificient)

$> nix-env \
--extra-experimental-features no-url-literals \
--option system x86_64-linux \
-f ./. -qaP \
--json \
--meta \
 --show-trace \
--no-allow-import-from-derivation | \
jq 'to_entries[] | select(.value.meta.maintainers == []) | .key' -r

(thanks pbsds)

  1. Sort the results by seriousness
  2. Redo 1 including silently-retired maintainers

Technical Details

Please cite this issue (#327779) when you bump such cases.

@AndersonTorres AndersonTorres added the 5. scope: tracking Long-lived issue tracking long-term fixes or multiple sub-problems label Jul 17, 2024
@Sigmanificient
Copy link
Member

Sigmanificient commented Jul 17, 2024

I suggest this command to retrieve all packages without maintainers

grep -rP "maintainers\s*=\s*(with\s*(lib.)?maintainers;)?\s*\[\s*\]\s*;" .

see the full list (2744)

@pbsds
Copy link
Member

pbsds commented Jul 17, 2024

one not reliant on grep trickery:

nix-env --extra-experimental-features no-url-literals --option system x86_64-linux -f ./. -qaP --json --meta --show-trace --no-allow-import-from-derivation | jq 'to_entries[] | select(.value.meta.maintainers == []) | .key' -r

https://gist.github.com/pbsds/bd6c82bd91e01d4dbc656d54a500649a

@Sigmanificient
Copy link
Member

one not reliant on grep trickery:

nix-env --extra-experimental-features no-url-literals --option system x86_64-linux -f ./. -qaP --json --meta --show-trace --no-allow-import-from-derivation | jq 'to_entries[] | select(.value.meta.maintainers == []) | .key' -r

https://gist.github.com/pbsds/bd6c82bd91e01d4dbc656d54a500649a

Oh wow it captures twice as much packages, I wonder where they come from

@chewblacka
Copy link
Contributor

Oh wow it captures twice as much packages, I wonder where they come from

About 1250 are duplicates, namely:

python311Packages.XYZ and python312Packages.XYZ

@Sigmanificient
Copy link
Member

Ah I see 😅

@AndersonTorres
Copy link
Member Author

Duplicates and autogen packages like MELPA...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5. scope: tracking Long-lived issue tracking long-term fixes or multiple sub-problems
Projects
None yet
Development

No branches or pull requests

4 participants