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/
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
