Benny Siegert <bsiegert%gmail.com@localhost> writes: > Go 1.20 will require Go 1.17.13 or newer for bootstrapping. That combination of language spec change and belief that it's ok to require recent self-hosting is unfortunate, but that's not unusual! > 1. Depend on go118 and use that for bootstrapping. Go 1.17 had a few > issues on NetBSD, so 1.18 is a better choice. This means that > installing Go 1.20 from scratch will first build go14 (which is in C)p, > then go118, then go120. This seems entirely reasonable. As long as it is feasible to bootstrap from C, I think we should have a first-class method, really the primary method, to do that. The way go has worked by building go14 and then newer go has been in my view 100% satisfactory, and a chain length of 2 is really not a big deal. Building go is just not on my radar of pain. > 2. Use go-bin for bootstrapping -- apart from the fact that the > aarch64 version is too old. The concern, of course, is that you have > to be confident in a binary bootstrap kit. I will observe that in the case of rust, there isn't a solid basis to be confident. In practice managing binary bootstraps soundly requires either some kind of assured infrastructure and chain-of-custody type management, or reproducible builds. And the first method is still shaky. If there are going to be binary bootstraps, I think that it should be part of pkgsrc, and accessible by anyone, to construct them, and ideally to be able to diff them against the published ones. In other words, just an optimization. > Should we offer both possibilities? Which one should be the default? I see it as 99.9% mandatory to offer the no-binary-bootstrap method (where using a C compiler doesn't count as that's part of base, and because bootstrapping C is a sub-problem being worked on https://www.gnu.org/software/mes/ ). This paper is interesting reading, and I would say that making binary kits primary is a step backwards: https://arxiv.org/abs/2202.09231 https://10years.guix.gnu.org/static/slides/08-courant.pdf https://10years.guix.gnu.org/video/camlboot-debootstrapping-the-ocaml-compiler/ I think it's perfectly ok to have a binary kit optionally used if that binary kit can be built reproducibly, and there is a trivial way to build it (without using some other go binary) and then "cmp" with the binary kit (pieceise unpacked, ahtever), ideally scripted. We should also think about the distinction between bootstrap kits and binary packages that one can download. I've set up DEPENDS_TARGET= bin-install clean and am in the habit of `pkgin ar`. With bin-install, it doesn't hurt much as future builds just install things as needed, but they are doing so from binary packages I built. I could see this being extended to fetch a go117 binary package when building go120. but then I wonder why that should be special. If so, why wouldn't someone fetch gcc8 when they need to build any random program that needs C++17? This is sort of arguring for source builds being source, and binary builds being easier to flip in. Of course, for mainline rust this is vastly harder since one needs a vast number of steps, perhaps over 20 by now, to the point where I don't see this happening. I would also say that unless we have a story about soundness of binary bootstraps, then as long as a multistep build is feasible (less than a day on a machine from 4 years ago), then we should just have the multistep build. People who want binary packages can use them; we shouldn't turn building from source into installing binaries -- we have a different way to spell that. (I haven't spun up guix yet but am intrigured.)
Attachment:
signature.asc
Description: PGP signature