Rolling release has become all the rage, sadly. On Wed, Oct 21, 2026 at 12:46 AM Julian Ospald via ghc-devs < [email protected]> wrote:
> I can comment on the distribution part quite confidently: > > 1. If GHC is going to require 3rd party binaries (like buck2) for > bootstrapping, it probably won't make major distributions drop it, but > there's a fair chance smaller distros will and the migration may be > costly for the rest and cause delayed updates. Even Gentoo, which has > historically packaged all sorts of esoteric build systems, does not > package buck2. BSD does neither and there are no upstream binaries. > > 2. While trying to include buck2 in ghcup > (https://codeberg.org/haskell/ghcup-hs/issues/1401), I was also rather > offput by the lack of proper versioning scheme and everything being > prereleases. Maybe this is the way with modern git and AI development, > but I'm not sure how I, as a distributor, am going to judge which one > is a usable/good/stable release. > > Sure, I could try to absorb all of those issues in ghcup... figure out > what releases are usable, clean up their build artifacts, build on > freebsd and other platforms that GHC supports... but I'm not sure this > is a good use of my time. > > If buck2 is opt-in... then all those problems are not very hard. Power > users can use it anyhow. > > On Tue, 2026-10-20 at 13:58 +0200, Magnus Viernickel via ghc-devs > wrote: > > Hi All, > > > > I think I agree with Ben's sentiment here, there's quite the high > > barrier to adopting a new third party build system, that is not > > surpassed by downloading a binary in `./boot`. > > > > I think the first barrier to clear is asking all packagers that are > > shipping GHC in their repos if they'd even be willing to package > > buck2. > > To me it appears that a project that seems more like a source > > available > > internal product than a free and open source software that doesn't > > have > > any maintenance guarantee or versioning scheme is something that most > > packagers won't package, and they for sure won't do that just to keep > > shipping GHC. Most packagers are unpaid volunteers who would really > > like > > to avoid churn. They are also our gateway of having GHC be actually > > used > > by most people. There should be a VERY good reason for us to cause > > such > > immense churn as using buck2 as GHC's build system would be. I don't > > think any of the already named reasons qualify. > > > > I also think that moving GHC even further away from being > > "bootstrappable" in any reasonable sense of the word by requiring a > > third party's binary to be downloaded (are there buck2 binaries that > > work on FreeBSD? MacOS x86? PowerPC? alpine linux i386? loongarch?) > > to > > even start building it is not a good trajectory. > > > > That being said, I think it's nice to have more ways to build GHC! If > > the buck2 build of GHC will just live outside of the GHC tree and > > just > > gets updated so that companies who regularly build GHC with their > > patches or even contributors who like it better than hadrian can use > > it, > > that would be great! > > > > I just don't think that it should become the liability of the GHC > > maintainers or downstream packagers. > > > > Best > > > > Magnus > > > > On 10/20/26 03:48, Ben Gamari via ghc-devs wrote: > > > Brandon Allbery via ghc-devs <[email protected]> writes: > > > > > > > FWIW what I've heard from packagers over the years is that > > > > Hadrian is an > > > > unwanted pain point for them. > > > > > > > While I have heard similar things about Hadrian, it does not seem > > > to me > > > that Buck2 is going to be better in this regard. While I am certain > > > that > > > Buck2 has many merits, as far as I can tell it is not maintained in > > > a > > > way to make it easy to consume by open-source packagers or > > > potential > > > dependees: > > > > > > * The project does not appear to have a versioning scheme beyond > > > datestamps > > > > > > * as far as I can tell there are no formal release notes or > > > changelogs > > > provided; CHANGELOG.md is, amusingly, only 28 bytes long > > > containing > > > the string "- Initial version" > > > > > > * the GitHub release artifacts [1] themselves are a collection of > > > files > > > with neither descriptions nor, in many cases, file extensions > > > > > > * it appears [2] that there is currently no formal release process > > > and the recommended practice appears to be use the tip of `main` > > > > > > This does not strike me as the sort of package you would want to > > > take as > > > a dependency outside of a monorepo. As far as I can tell, the only > > > packaging of Buck2 provided with a formal OS distribution is in > > > `nixpkgs`. I think that this is quite symptomatic of the problem. > > > > > > All of this is to say that Buck2 isn't something that I would feel > > > comfortable telling GHC's packagers that they need to package and > > > consume. It is already hard enough to get people to package a > > > compiler > > > like GHC; then demanded that they *also* package a build system > > > which > > > isn't maintained in a FOSS-friendly manner is only going to > > > exacerbate > > > this problem. > > > > > > Naturally, this could change if Buck2's maintenance changes. > > > However, > > > until then I would be opposed to going this direction regardless of > > > whatever merits the build system itself might offer. > > > > > > Cheers, > > > > > > - Ben > > > > > > > > > [2] > > > https://github.com/facebook/buck2#-warning---rough-terrain-lies-ahead > > > > > > _______________________________________________ > > > ghc-devs mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > _______________________________________________ > > ghc-devs mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- brandon s allbery kf8nh [email protected]
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
