[Exherbo-dev] On burying ::haskell

Mykola Orliuk virkony at gmail.com
Sat Aug 18 10:58:23 UTC 2018

I'd like to vot against burying ::haskell.
I don't see how this solves anything except of freeing some time for people
who are dedicated to maintain ::haskell. If you'll move it to
::haskell-unofficial then you can achieve same, I guess.

I agree that GHC libs management in source-based distros is awful.

But I hate managing packages with stack/cabal. They pollute home folder and
provides no friendly way to manage what was installed. I'd say that they
succesful only because they provide no meaning of re-build or remove libs.
They might be good for dev as build and then throw away, but I don't see
them as replacement for system packages.
Other point is that you have to manage external libs and tools dependencies
for them manually.

I'm not sure how Nix handles re-builds since you should either patch
"hashes" generation or re-build all dependant packages (like in Docker).
But slotting in Exherbo worked for me as long as I was careful.
So far, most my issues were related to outdated GHC. Bumping packages with
dependencies handling is pretty simple for me.
Sometimes I use ex-packages.rb older --match dev-haskell/\* dev-lang/ghc to
get all dependant packages re-built if I changed their root. Kinda replaces
http://hackage.haskell.org/package/haskell-updater .

- 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)
Yes. And reason for that is Exherbo policy. You have issues - you fix it.
For long response on reviews - not enough people for official repos, I
guess. Sometimes I consider making own fork of ::haskell because of that.

- updates are a pain with frequent failures, due to broken packages
> during upgrades
This should be true for any package manager including native Cabal. If
source don't provide proper dependencies or don't fit updates of others -
you get same issues.

- haddock options and others are a nightmare to enable/disable
I'm not sure about this. I have them enabled for dev-haskell/* . I remember
there were some incompatibilities between sorce code and haddock version.
But that was short and mitigation - disable haddock for that package.
Though correct fix, probably, is to add optional build blocker.

> - incompatible package configurations, paludis barfs out a lot telling
> you there is no build plan (because there is not)
That's probably because we tend to skip proper flags support when we write
Exherbo packages. exherbo-cabal still use default settings and gives no
control to Exherbo.
This is something that I wanted to work on for a long time but never
managed to start.

- bumping is complicated, because you have to fix/bump half of the
> ecosystem at once
Again. This is true for any package manager including cabal/stack/nix. I
guess someone already experimented with using Stack snapshots to maintain
set of package versions that can be succefully built together. Though that
goes a bit against source-based package manager's freedom to have multiple

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: ...
I think those 95% of the people don't use Exherbo as well. I guess there is
a lot of forgotten packages some of which even didn't got proper cross

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.
That happens always when you have fine-grained packages instead of bundles,
platforms and "batteries included".

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?

I'm not sure I can agree with that.
When I saw Paludis first time with ideas of supporting different formats of
repos I thought that's the one that will be able to handle all these
CPAN/Gems/Hackage/etc. But it didn't go further than minimal Exherbo

> 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.

And that's true for Cabal infrastructure also and they even have special
message for that:
"Warning: This package indirectly depends on multiple versions of the same
package. This is highly likely to cause a compile failure."
but they allow it. This means that there is a cases when it is ok.
Note that you can run in a same issues with non-Haskell packages that don't
use fixed slots in their dependencies.

> 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.
Agree. At most we may specify major version (as per PVP) in slot.
3 years ago there were proposal for tags
https://gist.github.com/ony/17ef2294818601e001f9 but it wasn't picked up.

My proposal is:
> 1. bury ::haskell
I think most of the issues and reasons can be applied to Exherbo itself.
Isn't it? For me most of the problems you mentioned are not specific to
::haskell (except of slow reviews).

For me it feels like Paludis abandoned for years already. I tried to start
working on it to get pluggable repo formats, but I quickly gave up because
of specific codebase (as for me) and a bit unpleasant contribution

I just see this decision for me not far from giving up on Exherbo
completely. Though I cannot say if I'm lazy or trying to think in
constructive way. But I still use Exherbo and justyfing all this issues by
my personal inactvitiy in resolving them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20180818/c6943929/attachment.html>

More information about the Exherbo-dev mailing list