Formalising our stance regarding binary distribution of cabal-install

[Kleidukos]

I am growing increasingly convinced that the line between us, the upstream development team of Cabal & friends, and the distributors of the cabal-install tool is blurred.

Currently we have the following distribution channels:

• https://downloads.haskell.org/cabal: The "official" bindists produced by our gitlab release pipeline. It's not clear which downstream users benefit from it, as it is a subset of what ghcup distributes;
• GHCup: Through its own channel, distributes a wider variety of bindists, especially for platforms not maintained by the GitLab pipeline;
• Binary Distributions will build their own bindist because they will want to have a say on some lower-level linker & compiler flags, and they also get quite pissed off if they have to ship upstream binaries, see https://wiki.debian.org/Hadoop;
• Source Distributions don't care too much about our bindists.

Looking at these, I have the impression that we're not really using our time correctly in the Cabal team, since our bindists are neither covering all architectures that are requested, nor used by most of distribution channels.

I would like to ask our distributors if this impression is correct, and if there is something the Cabal team can focus on to ease their life, should we disengage from producing bindists ourselves.

---

CC

@juhp for Fedora,
@arrowd for FreeBSD,
@blackgnezdo for OpenBSD,
@depressed-pho for NetBSD,
@branchvincent for Brew,
@hololeap and @solpeth for Gentoo
@rd235 for Debian,
@doko42 for Ubuntu,
@peti for OpenSUSE,
@maralorn for NixOS,
@hasufell for GHCup.

(Please indicate if someone else is better suited for your distribution.)

[blackgnezdo]

OpenBSD builds from source using the ports system. We don't even rely on the source tarballs from hackage due to them not having the bootstrap files #7289.

[hololeap]

Gentoo builds Cabal from source as a part of GHC and/or from hackage sources. cabal-install is built purely from hackage sources.

[maralorn]

nixpkgs builds Cabal together with ghc. For that we use the Cabal source distributed as part of ghc. For bootstraping we use ghc bindists which I think include Cabal bindists, which I guess are built by the ghc release pipeline.

We build cabal-install and e.g. other versions of Cabal from hackage sdists.

[angerman]

While not mentioned in the ticket, Haskell.nix also builds from source and never uses binary dists.

[hasufell]

Since cabal upstream has refused to accept my contributions to improve release CI to make it fit GHCup's needs, I stopped relying on it and now build my own binaries.

Further, questionable opinions/practices have reinforced my belief that it's better to not rely on cabal's shipped binaries, given that I have to keep reminding them of botched releases, as well as security backport requests being ignored.

[gbaz]

I think we will find that distribution channels, almost by definition, build their own binaries. Ghcup was an exception and has since changed its practices. That said, I do think binary releases are important as part of what it means to be an upstream maintainer and source-of-truth even if most users get their binaries through other channels.

However, this ticket seems to mainly be focused on acquiring information about who produces their binaries. (all distributions, I think?) and not on what a sensible process is for us as maintainers, and doesn't have what looks to be a particularly worked-through proposal for how we might change.

My view is that the actual production of bindists is not a central source of work to cabal maintainers, but the fact of needing to produce such helps conceptually tie together work that is important. I think that ceasing to produce such binaries could well lead to release management starting to fall apart, as the production of a set of binaries as a "release artifact" is an important unifying concept that helps ensure all other strands of work fit together.

[hasufell]

I agree with @gbaz and would encourage cabal team to just go ahead with whatever binaries they already have produced.

It might make sense to adjust documentation and communicate to end users that these binaries are really just a side effect of the release process and may contain bugs and issues not present when pulling from your distro or building from hackage.

As a result, this would also allow you to minimize the bindists produced to just:

• static alpine linux x86_64
• windows x86_64
• mac aarch64

And drop everything else.

As regards to index state pinning: drop it and make sure you also distribute plan.json (which you already do).

---

Please go ahead with the release and don't delay it further with all these discussions.

[andreabedini]

I wish that producing binary releases wasn't so hard but given the situation I agree we should leave it to more experienced distributors. The time saved can be better used elsewhere.

[peti]

openSUSE does not use cabal-install binaries from upstream. We build those ourselves using the source tarballs available from Hackage.

[arrowd]

OpenBSD builds from source using the ports system. We don't even rely on the source tarballs from hackage due to them not having the bootstrap files #7289.

Same for FreeBSD

[juhp]

I think this ticket is about cabal-install so no need for people to chime in about ghc Cabal, unless you use non-ghc Cabal which would be interesting info indeed. :-)