This could be used for automatic remove aliases:

$ git diff HEAD..f49f00d152e204f559a6ebf29ec853cfde2d2105 pkgs/top-level/all-packages.nix | grep '^+.*= .*callPackage' | awk '{print $2}'

mht2htm
pbpst
bareos
ori
flashtool
gnokii
i-score
kippo
mbox
meo
namazu
openmvs
openmodelica
screencloud
tlspool
chaps
aliceml
hhvm
metaocaml_3_09
love_0_9
nix-exec
proglodyte-wasm
betaflight
inav
fedpkg
jamomacore
pants
gnutls-kdh
gtkmathview
gdata-sharp
ilixi
qxt
myserver
openfire
ofp
lobster-two
qmc2
r3rs
avxsynth
bitkeeper
clfswm
foo-yc20
photivo
mi2ly
monodevelop
natron
notbit
beret
hawkthorne
privateer
alliance
ncbi_tools
plm
hol
jonprl
lean2
opensmt
otter
openspace
fakenes
imatix_gsl

Before merging this, someone should maybe check if any of these packages haven open PRs that fix them, that just got stuck.

I assume and hope that this is not the case, but it should probably be done anyways.

Oh and I forgot to mention that this is actually a relatively conservative estimate/implementation. It only handles packages for which .meta.position returns something useful and I generally tried to err on the side of caution.

If anyone ever needs them again, they can revert the respective commit.

It may be hard to know that these packages once existed in nixpkgs, though. So someone wanting to (re-)add one of the these packages to nixpkgs might end up writing an expression from scratch when they could have started from the old broken expression. (In fact just now I was poking around to see if I could fix natron -- if this PR had been merged already, I doubt I would have noticed that there was already an expression for it in the git history.)

Maybe it would be good to write the names of these removed packages in a text file and store it somewhere in the repo, so that it would be found with a simple grep of the repository for the name of the software.

so that it would be found with a simple grep of the repository for the name of the software.

In general, searching GitHub is always a good idea, because there might already be a ready but unmerged or WIP PR open.

Which isn't to say we shouldn't keep a list of dropped packages around, but just something I've run into at least once before. Especially with niche software, finding a reviewer and merger can be hard.

Ok, so I did the searches, here are my results:

Someone already wanted to drop jamomacore and i-score in #104446, there was some debate, apparently there's an active fork of i-score which will have a release. We might want to keep it around, but we might also just want to re-init that, depending on how similar the packaging will be.

Somebody noticed that natron was marked as broken and opened #103029, so we know there's someone who uses this.
They appear to be using the flatpak version now. We might want to look into fixing this one.

monodevelop was reported as broken in #35211 and the reporter "spent ~4h trying to bump to 7.3.3.17" in February of 2018. The only response they got were one ":thumbsup:".

Someone tried to bump opensmt in #102421 in November, so we might not want to drop that. On the other hand, this was broken since 2014 and @freezeboy does not seem like he actually plans on using it. Are you?

The openmvs build was fixed and the package was bumped in #98134, which is waiting for review.

I hope I haven't missed anything. I have not done anything with these findings yet.

Edit: I forgot about #54383, which tries to fix openmodelica, but has been WIP since January of 2019.

Maybe it would be good to write the names of these removed packages in a text file and store it somewhere in the repo, so that it would be found with a simple grep of the repository for the name of the software.

I noticed that there are a lot of entries in pkgs/top-level/aliases.nix where a package name is aliased to a throw, explaining that the package has been removed from nixpkgs for some reason or another. That seems like a better solution than my suggestion of just creating a text file somewhere, especially since it will cause a conflict if someone tries to re-add the same attribute name to all-packages.nix. That way, if someone forgets to search the repo or github before trying to write a new expression for one of the removed packages, they'll at least be forced to notice the existence of a prior expression when they get a build error during testing of their new expression (assuming they picked the same attribute name as the old expression had).

In fact i am stuck on this package as cmake is using FetchContent

We can drop it

Turns out, I don't care enough about this, after all.

Is this still of interest to anyone?

I am interested. Maybe @ajs124 could share the script that was used for this.

@Mic92 Yes I think nixpkgs needs more scripts to remove stalled things to avoid bloat. It is easy to add stuff, so removing stuff should also be easy when unmaintained/broken

(perhaps we should move conversation into a separate issue/RFC)

I have a concern that it would make it harder to take advantage of previous packaging attempts. Perhaps a broken package only needs some tweaks to unbreak but removing it would make the past attempt harder to find.

(perhaps we should move conversation into a separate issue/RFC)

I have a concern that it would make it harder to take advantage of previous packaging attempts. Perhaps a broken package only needs some tweaks to unbreak but removing it would make the past attempt harder to find.

I think there is an easy fix. We could add the commit where a package was removed in the message of nixpkgs/pkgs/top-level/aliases.nix so that when somebody wants to repackage it, they could just checkout this commit.

Adding the alias will need to be a separate commit then from removing the expression.

If you want to see if there is an older package you can use git log --grep. Sure, sometimes one may not be able to find a package but I really do not think it is worth us spending more time on packages that are broken for the small chance somebody someday will want to pick it up again.

If you want to see if there is an older package you can use git log --grep.

Perhaps we could put this in the documentation somewhere.

I really do not think it is worth us spending more time on packages that are broken for the small chance somebody someday will want to pick it up again.

Agree. While Nixpkg's size is impressive, we do need to have some baseline quality and a 1-year timeout for broken packages seems reasonable to me.

Adding the alias will need to be a separate commit then from removing the expression.

If you want to see if there is an older package you can use git log --grep. Sure, sometimes one may not be able to find a package but I really do not think it is worth us spending more time on packages that are broken for the small chance somebody someday will want to pick it up again.

Well. if we would automate it this could be added as a feature. But we probably don't need to ask contributor to provide it otherwise.