Delete erroneously uploaded package versions

[borsboom]

This is motivated by the fact that last week I mistakenly uploaded an weird stack version (9.9.9). I asked the Hackage admins to remove it, but was told that there is currently no ability to delete package versions in hackage. Admins did tell me that it's not a difficult feature to add and that it's something they want to do, so posting this issue to make it easier to track it.

Aside from fixing dumb mistakes, there could be important reasons this needs to be done, such as copyright violation or other illegal content.

Deprecating a version helps a bit, but I found it did not prevent cabal install stack from installing the 9.9.9 version (however, giving it impossible dependency version bounds did the trick).

I am happy to work on a PR to implement this myself, but it would be most helpful to have someone nudge me in the right direction before I start.

[hvr]

however, giving it impossible dependency version bounds did the trick

if you do that, please use the unofficial convention and add a build-depends: base<0 line near the start of the library-stanza and add a ---comment right above that line explaining why, as that's a clear signal that this was done deliberately (and also why)

[dcoutts]

@manny-fp unfortunately this is going to get harder to implement not easier, because we'll soon be serving an append-only log of all the package uploads and changes (think git like, only additions, never rebasing). So as a matter of policy, I'd prefer to only delete things when we're really compelled to by legal reasons (copyright, illegal content etc).

[adamgundry]

Duplicate of #112?

It seems to me that there are several cases we may need to deal with here...

Mistakes in uploads of otherwise-permitted content (e.g. stack-9.9.9)
The combination of deprecation and build-depends: base<0 is a good start, but we might want some more explicit way to mark packages as erroneous (e.g. so that cabal will not always report latest: 9.9.9 for stack). I guess this is not too difficult, since it's just a presentation issue. The content would still be available for people who have frozen build plans involving it, or who go digging through hackage, but this should be enough for most cases. Hopefully this would satisfy most authors wanting deletion, and it could be made available to maintainers.

Tarballs that cannot be distributed
Presumably it wouldn't be too hard to remove/replace the tarball/source and update the .cabal file to a new deprecated revision? Of course, we'd want the mirrors to notice that the content was gone, not just temporarily not available, and that is rather more tricky. We can't guarantee that mirrors respect this, but we can make deleted packages return 410 Gone responses, and implement the necessary changes in the mirror clients. Probably this should be available to hackage admins, but not package maintainers, and used only for removing copyrighted/illegal content.

Cabal files that cannot be distributed
Here I'm assuming that all traces of the .cabal file have to be removed. This is rather more tricky, due to the existence of the append-only log. In principle, we could rewrite the index from scratch, which would force all clients to download it non-incrementally. But I guess this is rather unlikely to be needed in practice.

[borsboom]

This is slightly different than #112 in that it's about removing a specific version of a package, rather than the whole package. But it's close enough that merging the two issues probably makes sense. I'd definitely be happy if the resolution is hiding deprecated versions by default.