tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Go 1.20 and bootstrapping

Benny Siegert <> 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

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

).  This paper is interesting reading, and I would say that making
binary kits primary is a step backwards:

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

Home | Main Index | Thread Index | Old Index