Missing GHC 8.8.1 boot libraries

[tfausak]

GHC 8.8.1 was released more than two weeks ago. Many of the boot libraries are not on Hackage yet. Someone made a Reddit thread about it, which is how I noticed.

Based on the output of stack --resolver ghc-8.8.1 exec ghc-pkg list, the following packages are not on Hackage:

• base-4.13.0.0
• bytestring-0.10.9.0
• ghc-8.8.1
• ghc-heap-8.8.1
• ghci-8.8.1
• libiserv-8.8.1
• rts-1.0

Whereas these packages are currently available: Cabal-3.0.0.0, array-0.5.4.0, binary-0.8.7.0, containers-0.6.2.1, deepseq-1.4.4.0, directory-1.3.3.2, filepath-1.4.2.1, ghc-boot-8.8.1, ghc-boot-th-8.8.1, ghc-compact-0.1.0.0, ghc-prim-0.5.3, haskeline-0.7.5.0, hpc-0.6.0.3, integer-gmp-1.0.2.0, mtl-2.2.2, parsec-3.1.14.0, pretty-1.1.3.6, process-1.6.5.1, stm-2.5.0.0, template-haskell-2.15.0.0, terminfo-0.4.1.4, text-1.2.4.0, time-1.9.3, transformers-0.5.6.2, unix-2.7.2.2, xhtml-3000.2.2.1.

Can these packages be uploaded? And since this seems to happen a lot (#203, #192, #179, #160, #153, #141), is there anything I can do to help automate this in the future? Thanks!

[RyanGlScott]

FWIW, I don't think the rts library was ever intended to be uploaded to Hackage, as it's only used internally by GHC and doesn't expose any modules (i.e., no Haddocks).

I seem to recall that there is a bug that makes it difficult to upload ghc-heap to Hackage, although I can't recall what it is off the top of my head. Perhaps someone in the know can fill in the details.

[RyanGlScott]

As far as bytestring-0.10.9.0 goes, see GHC #17110.

[tfausak]

Oh, good catch! I produced that list of packages pretty mechanically. Taking a closer look at them ...

• bytestring-0.10.9.0 isn't available, but bytestring-0.10.10.0 is.
• ghc-heap, libiserv, and rts aren't on Hackage at all.

[hvr]

is there anything I can do to help automate this in the future?

No.

[domenkozar]

Please? :)

[sjakobi]

Ben's mail on Haskell Cafe shines some light on the situation:

https://mail.haskell.org/pipermail/haskell-cafe/2019-October/131624.html

[domenkozar]

So in summary, there's a huge backlog of work, but while people are stepping up to help, there's no interest in delegation. Looks like a superhero syndrome to me.

[bgamari]

This issue has been mentioned on haskell-cafe where I describe the current state-of-play.

[tfausak]

Based on your explanation, this is a manpower problem. Yet the help of many people (including @bgamari, @RyanGlScott, and me) has been rejected. What can we do? Looking at the hackage-server repository, I can't find any work in progress (issue, project, branch, or pull request) to help with.

[gbaz]

The problem to be clear is not about helping to "upload the libraries" -- that's the easy part! The problem is updating hackage-server to the new Cabal library, which is a fair amount of work, and tricky. As far as I know, ben has started to do some stuff in this direction. As in all such cases what we need is not "drive by" help, but at the end of the day more core maintainers of hackage-server.

[bgamari]

In the interest of making the hackage-server upgrade task more accessible to contributors I have opened haskell/hackage-server#852.

[codygman]

context: I landed here after following ghcide issues for ghc 8.8.1 and why ghcide-nix didn't support it yet and I found this very interesting comment section and have no idea what's going on.

The problem is updating hackage-server to the new Cabal library

Did anyone ever figure out why upgrading to Cabal v3 was necessary?

There was never a response to this query on Haskell cafe or anywhere else I could find.

Also, I see that more core maintainers were and are needed. Then I go on to read the quote below and see:

For what it is worth, I have asked several times whether I can help with
the upload process but have been turned down repeatedly. I can't
claim that I fully understand the reasoning behind this, but I can
nevertheless respect the decision. - @bgamari

This makes me feel that I too could be turned down with no explanation if I offered my help and I'm sure it leaves others with this impression. I'm left feeling confused and kind of put off. Some clarity here would help extinguish that for me and others I think.

Could this lack of clarity be part of the problem for getting more core maintainers?

[codygman]

Also... I was tempted to avoid addressing but how in the world is this a constructive answer or acceptable behavior?

Is what seems to be an earnest request to help shutdown with "No" seen as acceptable by the Hackage trustees?

It seems I'm out of the loop and there is something personal going on here or another source of frustration I don't know about. I'd also like to help if possible, but I fear simply by commenting on these issues I could doomed to face answers like above in the future if I try to contribute.

[gbaz]

It was a yes/no question. So a yes/no answer is acceptable. There's plenty of ways you can help contribute to the ecosystem, including to hackage-server, and also to cabal-install.

Let me give a little more, but not all the context: For complicated reasons, uploading "base" is not like uploading a normal library, not least related to the fact that it isn't reinstallable. Some of the plumbing changes going on have a long term goal of making it more installable. But to upload base-as-it-stands means that we need to use the cabal library that understands those intermediate changes. Context-dumping all the details is difficult. There are a lot of moving parts. A lot of updating hackage-server to the new cabal lib isn't just "chasing types" but working out how to interact with all the new semantic changes.

I know you're not happy with the answer given above, hopefully this helps clear things up.

And a final plea: please don't be rude to the people doing the work if sometimes they give short answers -- they, like all of us, are busy, and only have so many cycles to spare.