# Head.hackage usage, rationale, and problems

**URL:** <https://discourse.haskell.org/t/head-hackage-usage-rationale-and-problems/9345>\
**Category:** Uncategorized\
**Created:** [April 16, 2024, 1:22pm UTC](https://discourse.haskell.org/t/head-hackage-usage-rationale-and-problems/9345 "2024-04-16T13:22:15Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [April 17, 2024, 7:14am UTC](https://discourse.haskell.org/t/head-hackage-usage-rationale-and-problems/9345/10 "2024-04-17T07:14:52Z")

</div>

> [@bgamari](#):
>
> I think it is defensible to say that we shouldn’t actively encourage `head.hackage` usage by end-users (as `ghc.X.hackage` would have done).

The main reason I don’t like `head.hackage` it not even that.

`head.hackage` is a pool of patches from different authors and I as an end-user have no easy way of knowing whether those patches are:

- correct
- have been submitted upstream
- have been approved upstream

You don’t even write such information in the patch header: [patches/lens-5.2.3.patch · master · Glasgow Haskell Compiler / head.hackage · GitLab](https://gitlab.haskell.org/ghc/head.hackage/-/blob/master/patches/lens-5.2.3.patch?ref_type=heads)

To me that is enough reason to prefer going through all the PRs and issue trackers and cooking up source-repository stanzas instead.

---

_[View the full topic](https://discourse.haskell.org/t/head-hackage-usage-rationale-and-problems/9345)._