[Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently

[Niklas Hambüchen]

I'm writing this after having spent many hours of debugging why the
packages "entropy" and "happy" have different compile-time behaviour
when taken from Hackage vs when taken from their upstream git repositories.

After lots of frustration, I finally figured out the problem:

These packages have "Hackage revisions", where their cabal files were
modified from its upstream equivalent:

* https://hackage.haskell.org/package/happy-1.19.5/revisions/
* https://hackage.haskell.org/package/entropy-0.3.7/revisions/

Here, "setup-depends" were added to the cabal file, in order to make the
package build correctly. These changes are on Hackage only, they cannot
be found in the equivalent release of the upstream git repository.

This is *extremely* confusing.

The practice of "fixing up" other people's cabal files behind their back
instead of making those fixes upstream prevents me to use their upstream
git packages to reproduce my issues.

It hides the fact that there is a problem with the upstream package.

In the case of happy, there is not even any upstream fix in the master
branch for the missing setup-depends:

* https://hackage.haskell.org/package/happy-1.19.5/revision/2.cabal vs
* https://github.com/simonmar/happy/blob/2d84ca0/happy.cabal

So in this case, I suspect that the silent "fix" has prevented the
upstream maintainer to even notice that there is a problem with his
package, and so it will be broken again when he uploads the next version.

I understand that the concept of Hackage revisions was introduced in a
commendable effort to improve the package users' experience: Nobody
likes when packages they want to use are broken. And it is clear that
something has to be done when upstream authors don't reply to pull requests.

But I believe this is not the case here.
The upstream maintainers of "happy" and "entropy" are Simon Marlow and
Thomas M. DuBuisson, who are very reliable getting stuff fixed (if they
know about it!) and they apply PRs quickly and their repositories are
well and alive.

I believe we're shooting ourselves in the foot with these fixes: The
time it takes to make an upstream fix and release it as a proper
revision is dwarfed by the time it takes you to figure out bugs when the
code you download from Hackage is not the code that the maintainer put
there, and when package maintainers don't even notice that their
packages are broken because of "silent fixing".

So I would welcome if we could make use of the "Hackage revisions"
feature only in the utmost necessary cases, or even better, never, and
always make properly versioned releases, where a change to any file
implies a bump of the version, so that one can clearly see if one is
dealing with the unmodified upstream code or not.

Greetings,
Niklas