[Exherbo-dev] On burying ::haskell

Julian Ospald hasufell at hasufell.de
Fri Aug 17 14:38:44 UTC 2018


The state of haskell packages in exherbo is pretty bad, but it is in 
most distros:

- GHC and haskell packages are horribly outdated (last time I provided a 
patch for bump we still had gerrit and no one cared about it for months, 
so I stopped working on it)
- updates are a pain with frequent failures, due to broken packages 
during upgrades
- haddock options and others are a nightmare to enable/disable
- incompatible package configurations, paludis barfs out a lot telling 
you there is no build plan (because there is not)
- bumping is complicated, because you have to fix/bump half of the 
ecosystem at once


There are a few reasons for these problems:

1. no one uses distro package managers for haskell in production, which 
is why there is little to no interest in improving distro support or any 
other ecosystem aspect. 95% of the people use one of these and they work 
mostly well:

- stack [0]: the most (in)famous haskell tool for building with a global 
cache, having different ghc versions in parallel and having a curated 
set of packages that are guaranteed to compile with each other and won't 
ever break API. Maintained by fp-complete, a haskell consulting company.

- cabal sandboxes [1] with local package state, which enables you to 
have incompatible packages in parallel, no sharing

- nix [2]: the only distro/PM that managed to be kinda compatible with 
the haskell ecosystem. In addition, it allows to write reproducible nix 
expressions that include native libraries.

- let's not talk about cabal new-build, it's buggy

2. The depgraph of haskell packages is complicated, because of PVP [3] 
and people very keen to break API in unpredictable ways. A lot of 
programs simply cannot be built inside the same depgraph, which is why 
we have sandbox and similar solutions. This is an ecosystem "problem" 
and cannot be solved.

3. Paludis is not designed for this kind of thing. It cannot (and should 
not) compete with nix, which is really the only PM currently out there 
that can handle it. And it's a huge hack. And even if it could, why 
would anyone invest a huge amount of time to make paludis work with it 
in all the ways that it is lacking compared to these tools? Also, the 
way we use slots for haskell packages is just broken and you can 
accidentally manage to build a program against 2 versions of QuickCheck, 
which will then outright fail. We don't have actual support for having 
different haskell packages installed in parallel. Our slotting here is 
just a failed attempt in providing seamless upgrades, which doesn't work.

4. Very very few packages actually depend on stuff in haskell. Pandoc 
maybe, a few other single packages. And that's it. Nothing significant, 
so there is no pressure keeping anything up to date.


IMO, there is no benefit in trying to fix it. It's just a huge amount of 
work for really little gain. As such we shouldn't pretend to support 
haskell packages.


My proposal is:

1. bury ::haskell
2. move dev-lang/ghc to ::arbor or somewhere else (maybe with 
dev-haskell/cabal-install, which is nice to bootstrap something up). 
That's enough for anyone to get started with haskell. You have a 
compiler, a repl and a way to install arbitrary packages. Nothing else 
needed.
3. Figure out what to do with packages that still depend on pandoc/other 
stuff from ::haskell

This minimal approach is what I've seen in other distros too. It works 
well and is low in maintenance. Bumping the compiler then is not a huge 
exercise of fixing a whole set of unmaintained packages anymore.


--

[0] https://docs.haskellstack.org/en/stable/README/
[1] http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html
[2] https://nixos.org/nix/
[3] https://pvp.haskell.org/



More information about the Exherbo-dev mailing list