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