Nixpkgs: Add common packages to Nixpkgs

[matthewbauer]

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=&notinrepo=nix_unstable&repos=&families=20-&repos_newest=&families_newest=

[vcunat]

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.

[FRidh]

We are missing quite a few KDE applications (mostly small games).

[vcunat]

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.

[FRidh]

Yes, @Profpatsch once wrote something about that as well. I would be very much in favor of an RFC on that topic.

[7c6f434c]

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.

[Profpatsch]

I documented my ideas here: https://nixos.wiki/wiki/User:Profpatsch#nixpkgs_support_matrix

[matthewbauer]

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:

• Popular closed-source applications without a good alternative.

• Older software that is required as a dependency of other packages.

• Unstable versions of software

  • commonly used and packaged by other package sets.

  • where no stable version exists.

  • where the stable version is over 18 months old.

  • that is depended on by another package and no stable version
    will work.

I've outlined this in the doc here:

https://gist.github.com/matthewbauer/f8e36468b0dd84caff6a0d3ce3fd2b85

[FRidh]

to package the latest, stable version of all of the world’s open source software with a living maintainer

In nixos-stable or in nixpkgs-stable? The reason I am asking this is that the former is an actual stable release that has seen more testing whether the latter is rolling, which requires asymptotically an infinite amount of work to stay at the latest. I would much rather we spend time on say quarterly releases than rolling, because all the integration testing that is needed takes away from time that could be spend on actual improvements.

[7c6f434c]

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).

[7c6f434c]

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.

[matthewbauer]

In nixos-stable or in nixpkgs-stable?

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".

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.

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.

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.

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 (https://github.com/NixOS/nixpkgs/issues/40015 and https://github.com/NixOS/nixpkgs/pull/60348).

[stale[bot]]

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:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[Profpatsch]

Let’s close this, every package that somebody wants to use is either packaged on demand or requested in the issue tracker.