On 08/18/2018 06:58 PM, Mykola Orliuk wrote:
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.
Sorry to hear that, but those are the only de-facto tools that are
properly supported and everyone in industry uses. Just because you don't
like to use them is not a good argument for keeping dev-lang/ghc rotten
and having users try our giant mess of ::haskell.
The advantage here is *very* clear. Removing ::haskell will allow to at
least maintain the compiler properly, as a shortcut to getting started
with haskell without stack. Since my ncurses fixes we could even package
dev-lang/ghc-bin from the official binaries.
Since you haven't stepped up either fixing this mess, I am pretty
confident there is no one else left who is interested and has the
knowledge to do so. And again: it's pointless. I won't do it, because
exherbo has no use for being used at work here.
I would maintain a minimal haskell package set though, only containing
ghc and cabal-install. We could also switch to a rust-like approach to
building, not packaging libraries at all, only binaries.
I'm not blaming anyone here. I'm just stating the fact that no one wants
to work on it and it's a waste of time. So moving forward with a minimal
set is reasonable.
====== lots of bikeshedding =====
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.
Sure, system packages are global though and a global database in haskell
gives you unsatisfiable build plans very quickly. Let's not fool
ourselves here. Paludis cannot fix that problem. And this is NOT a
general package manager problem. This is ecosystem specific. It's the input.
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.
Slotting is broken. I pointed out the brokenness to you some time ago,
you had no answer either how those build failures came to be and why
something tries to link against two QuickCheck versions. So my
conclusion is, this is broken.
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.
*sigh* please see my last ghc bump, the fixes to your exherbo-cabal
package, to the exlibs... and everything was rotten, no one cared and it
was way too much work, for little gain.
https://github.com/ony/exherbo-cabal/pull/25
https://github.com/ony/exherbo-cabal/pull/26
And 20+ patches on gerrit that cannot be viewed anymore.
- 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.
No, because of our slots stuff gets broken in-between like you have with
Perl upgrades. Our slots are not proper, you can check how gentoo
handles this, which is slightly, better, but not good enough either, so
in the end you need a "fix-haskell-packages" tool. Doh.
In addition, exherbo-cabal tool lacks quite a lot of functionality, so
we would have to put a lot of work into that to properly automate and
then it would still be a mess.
- 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.
Then try to play with it a bit. Enable/disable it for a few single
packages, do some rebuilds, enable, disable and see everything being in
a broken state...
- 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.
No, I'm talking about the dependency graph.
- 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.
Using stackage versions would be way better and would at least fix the
depgraph problems. But it would still be a lot of work and then lock us
on that pre-defined set of packages. Adding a non-stackage package to an
existing stackage set is a nightmare.
I don't care about freedom if everything is broken. That's why I like
exherbo, it's not about "freedom" in terms of random USE flag choices.
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".
No. That's an ecosystem problem. It is possible to solve on hackage if
people start to think of hackage as a rolling release platform that has
NO upper version bounds. Fix compile failures as they occur, release a
fix, stop breaking APIs randomly. That's what works in C and even Go.
Since rust also followed the "semver" crap, they have the same problems,
everyone keen to break API and not keep their dependencies up2date.
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.
Nix is a huge design project and the primary focus is not correctness.
I'm really keen in hearing how you plan to introduce even a fraction of
its features to paludis without breaking every single principle its
creators stand for. And how you gonna get funding for those 2+ years of
development.
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.
Yes and in gentoo this is not possible. This is because of our wrong $PV
slots. This means we are as bad as the cabal resolver.
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.
No, definitely not. As explained above.
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.
So. Afaiu you don't have enough time to fix either paludis or ::haskell
alone to justify that we keep things the way it is. I think that means
we should move forward burying ::haskell (at least the way it is right now)
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
