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

[Benno Fünfstück]

At the very least, we should make sure that each revision is accompanied by
an upstream PR if it is for the latest release (or any other still
supported branch) and the project is hosted on some VCS service that
supports PRs.

Regards,
Benno

Niklas Hambüchen <mail at nh2.me> schrieb am Do., 22. Juni 2017, 18:16:

> 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
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170622/08a75094/attachment.html>