Before
Before this commit, gokr-packer was building all Go binaries to include in the
gokrazy root file system from the same working directory, meaning the same
go.mod and go.sum files were used for all packages.
This wasn’t really an intentional choice, instead it was the easiest way to get
things working when Go switched from GOPATH to modules.
The downside of that approach is that updates in one package can result in other
packages no longer building. In the most extreme cases, it can mean that two
packages cannot be built into the same gokrazy root file system at all.
After
With this commit, gokr-packer will build each package in a subdirectory of the
new builddir/ directory in your gokrazy instance directory,
e.g. ~/gokrazy/scan2drive/builddir.
If there is no go.mod file in the builddir yet, gokr-packer will copy the
top-level go.mod/go.sum files into the builddir to keep your current module
selection, and hopefully build exactly the same binary as before.
Influencing the granularity
Often, one Go package will be the only package you use from a certain Go
module. But this isn’t always the case: for example, the system packages
github.com/gokrazy/gokrazy/cmd/dhcp and github.com/gokrazy/gokrazy/cmd/ntp both
come from the github.com/gokrazy/gokrazy module.
gokr-packer will by default create a separate builddir, including a separate
go.mod and go.sum, for each package, even when they come from the same module.
If you want to add module-wide replace directives to your go.mod file,
you can influence the granularity at which gokr-packer works as follows.
Move the go.mod/go.sum files to the directory level within the builddir/
hierarchy at which you would like to work. gokr-packer will look for
go.mod/go.sum files at the package level, going one level up until it finds the
files.
Hence, you can use the following locations, ordered from finest to coarsest
granularity:
1. per-package builddir (default), e.g.:
builddir/github.com/gokrazy/gokrazy/cmd/dhcp/go.mod
2. per-module builddir (convenient when working with replace directives), e.g.:
builddir/github.com/gokrazy/gokrazy/go.mod
3. per-org builddir (convenient for wide-reaching replace directives), e.g.:
builddir/github.com/gokrazy/go.mod
4. single builddir, preserving the previous behavior, e.g.:
builddir/go.mod
related to https://github.com/gokrazy/tools/issues/38
The GOFLAGS handling is the opposite of how the Go tool handles it, where
GOFLAGS provides default values that the command line then overwrites. I think
it’s better to match that behavior.
Instead, allow extending gokr-packer’s list of build tags via the buildtags/
per-package config directive.
Also, add osusergo and netgo build tags by default so that even when cgo is
enabled, gokrazy code results in statically linked binaries.
related to https://github.com/stapelberg/scan2drive/issues/18
This is useful for running gokrazy on PC platforms (e.g. for
https://router7.org/), where the first systems without legacy BIOS support are
starting to ship.
The existing boot methods (Legacy BIOS MBR boot, Raspberry Pi) are unaffected by
this change and keep working.
Regardless of the bootloader (BIOS, UEFI, Raspberry Pi), we now use a GPT
partition table with hybrid MBR (= protective MBR + FAT32 /boot partition
which the Raspberry Pi bootloader requires).
This change should have no effect on existing installations.
To switch to GPT, you’ll need to use the -overwrite= flag to partition the
device (e.g. SD card). If you want to keep your /perm partition, you’ll need to
shrink the file system (using resize2fs) by 1 MB to make space for the secondary
GPT partition table copy at the end of the device.
Previously, the partition *table* contained a UUID that we used as root=
parameter for the Linux kernel, e.g. root=PARTUUID=471cad93-03
Now, individual partitions (not the partition *table*) have a UUID that begins
with 60c24cc1-f3f9-427a-8199,
e.g. root=PARTUUID=60c24cc1-f3f9-427a-8199-2e18c40c0004
fixes https://github.com/gokrazy/gokrazy/issues/87
