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