treewide: remove orphaned packages

[kampka]

Motivation for this change

Requested by @Mic92 in #109813 (comment)

[SuperSandro2000]

You need to add throw aliases for all of them and remove them from top level to make ofborg happy.

[Ekleog]

@Mic92 I know you asked Kampka to do this, but IMO this is a bad idea as long as we don't have popcon-like information about which packages are used. For instance, I know that mdadm was maintainer-less when I noticed it had last been updated since a quite long time ago when looking into a bug, and at that time I “took over” maintainership (though in practice it's not like mdadm is very active a project anyway so I haven't been doing that much).

All that to say, IMO even orphaned packages have some potentially significant value, at least so long as there are no known security vulnerabilities in them — removing them when there's no longer any maintainer listed basically means that we decide that nixpkgs is only a distribution for people who do maintain packages.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-nixpkgs-maintainer-wanted-for-trilium-server-gandi-cli-matrix-appservice-slack-and-spacegund/11095/1

[Mic92]

@Mic92 I know you asked Kampka to do this, but IMO this is a bad idea as long as we don't have popcon-like information about which packages are used. For instance, I know that mdadm was maintainer-less when I noticed it had last been updated since a quite long time ago when looking into a bug, and at that time I “took over” maintainership (though in practice it's not like mdadm is very active a project anyway so I haven't been doing that much).

All that to say, IMO even orphaned packages have some potentially significant value, at least so long as there are no known security vulnerabilities in them — removing them when there's no longer any maintainer listed basically means that we decide that nixpkgs is only a distribution for people who do maintain packages.

They also create work if we do treewide refactoring i.e. updating a central library that might break some other packages i.e. #109113 I asked on discourse if anyone wants to keep any of these packages. Also they make nixpkgs-review slower.

[stale]

I marked this as stale due to inactivity. → More info

[kevincox]

I agree. I think we should remove them if no one is stepping up. The packages will still live on in Git and are trivial to add back if someone wants to step up at some point in the future.

[SuperSandro2000]

Mic92 I know you asked Kampka to do this, but IMO this is a bad idea as long as we don't have popcon-like information about which packages are used. For instance, I know that mdadm was maintainer-less when I noticed it had last been updated since a quite long time ago when looking into a bug, and at that time I “took over” maintainership (though in practice it's not like mdadm is very active a project anyway so I haven't been doing that much).

mdadm is by default installed on other Distros and it is reasonable to assume that it is an important package unlike the ones that are removed here.

All that to say, IMO even orphaned packages have some potentially significant value, at least so long as there are no known security vulnerabilities in them — removing them when there's no longer any maintainer listed basically means that we decide that nixpkgs is only a distribution for people who do maintain packages.

If you are using a package which lags a maintainer and it is to significant value to you than you should step up as a maintainer otherwise the package will degrade over time. We can't put the maintenance burden of maintainerless packages onto the community and fix time along side when doing major updates of other packages. Maintainers can take away some of the burden and fix packages quickly after they broke in nixpkgs-unstable and it is very important that people actually use those packages in their day to day live to find more indepth bugs which someone just checking if the program starts would have never found.

[aanderse]

I always thought an Ubuntu style "multiverse" repo would be a good solution to this problem. See this discourse thread for additional discussion on the topic.