-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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
Add common packages to Nixpkgs #60005
Comments
I think we quite often have them, but they are either not detected or under a different name (or similar issues). Anyway, these mismatches might better get solved in most cases. |
We are missing quite a few KDE applications (mostly small games). |
If we're to expand the list of packages significantly, we perhaps finally need some way of distinguishing well-maintained packages from the rest – perhaps package tiers in spirit similar to the platform RFC. EDIT: now we mainly have the "tested" job (and "unstable" job), in this sense. |
Yes, @Profpatsch once wrote something about that as well. I would be very much in favor of an RFC on that topic. |
And from my gist (linked in the RFC) one can see that package support tier RFC is also in the plans, but I want to learn as much as possible from the platform one first — or let someone else do it.
|
I documented my ideas here: https://nixos.wiki/wiki/User:Profpatsch#nixpkgs_support_matrix |
In my opinion, the Nixpkgs mission statement should be:
Everything else requires some consensus that it is generally useful. Valid exceptions include:
I've outlined this in the doc here: https://gist.github.com/matthewbauer/f8e36468b0dd84caff6a0d3ce3fd2b85 |
In |
In my opinion, the Nixpkgs mission statement should be:
> to package the latest, stable version of all of the world’s open source software with a living maintainer
Everything else requires some consensus that it is generally useful. Valid exceptions include:
I would also include useful unmaintained packages that still have value (either functional or historical significance) and can be built and used on modern systems in reasonable way.
We shouldn't actively support the harmful fiction that software maintenance is a good thing, it is nothing more than a reaction to unfortunate circumstances (either internal — bugs — or external — compatibility).
|
Staying at the latest only requires an infinite amount of work for thorough testing, though. My aim is to switch to a branch where updates are merged if they pass some fully automated testing and get reverted if they turn out to be a problem, not merged only after review. |
I am thinking about nixpkgs-unstable specifically. My main point is that the latest stable release should be the highest priority. Everything else isn't necessarily excluded but also isn't "tier 1".
Yeah I somewhat agree. My main point is to avoid the can of worms of supporting super old novelty type software. Those are certainly interesting, but should not be included in Nixpkgs. Having someone who is making new releases is definitely important. Nixpkgs shouldn't be too preoccupied with supporting legacy software, but we also shouldn't break it.
Yeah this definitely happens from time to time. But it should be considered bad practice for long periods of time. I'm much more worried about the case where someone adds a new version of a package but keeps old versions there forever, even though it's not especially useful (#40015 and #60348). |
Related to NixOS#60005.
Related to NixOS#60005. (cherry picked from commit 86a7609)
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
Let’s close this, every package that somebody wants to use is either packaged on demand or requested in the issue tracker. |
Issue description
Repology has a list of packages that are not in Nixpkgs, but included in many others. This is a useful way to find what is missing in Nixpkgs, or perhaps has incorrect names. Correcting this information is useful for Nixpkgs coverage and keeping things up to date.
All packagers not in nixpkgs, but included in at least 20 other repositories:
https://repology.org/projects/?search=&maintainer=&category=&inrepo=¬inrepo=nix_unstable&repos=&families=20-&repos_newest=&families_newest=
The text was updated successfully, but these errors were encountered: