This variable was semi-deprecated ages ago so `version.txt` could follow
a similar variable naming pattern to `os-release`. Finally drop usage of
it here in favor of `$COREOS_VERSION`.
The version of repos.conf/coreos.conf that catalyst needs isn't valid
for normal SDK chroots and causes env-update to spew errors when it is
run prior to update_chroot which configures portage properly.
SDK tarballs have a .DIGESTS file but it is created by catalyst instead
of the upload_image function. In order to support plain GPG signing but
not avoid re-generating .DIGESTS we need to move that code out of
upload_image to a new function. upload_files shouldn't do it itself
because it is also used for portage binary packages which shouldn't be
signed (there is no point, nothing would verify the signatures).
- Remove custom COREOS_* attributes from /etc/lsb-release
- Move dev image logic to dev_image_util
For extra fun fix detection of local host URL for devserver.
- Remove weirdly verbose "DESCRIPTION" format.
- Add COREOS_RELEASE_BOARD back to /usr/share/coreos/release
This is mostly just so update_engine and gmerge report the correct
board name to devserver, informative-only on prod images.
- Remove version info from /etc/gentoo-release
- Switch from 'track' to 'group' terminology.
Right now there is some funky logic to either use a previous build as a
seed or the current SDK tarball if it happens to have been downloaded.
This is a bit confusing and doesn't work reliably since it is reasonable
for there to be neither a previous build or the current SDK available if
the SDK chroot was created some time ago. Fix this by using the new SDK
library and always use the latest SDK, downloading it if needed.
Sync up bootstrap_sdk with other tools by using the common upload
functions. As part of this refactor release_util a bit to provide a
truly generic upload function.
The name "coreos-sdk-amd64-..." makes much more sense for general
distribution than "stage4..." so after catalyst is done rename the final
tarball and fixup the DIGESTS file to refer to the new name.
This uses Gentoo's catalyst for very thoroughly building images from
scratch. Using images based on this will eliminate some of the hackery
in make_chroot.sh for building up the sdk from a stock stage3 tarball.
For reference the procedure it performs is this:
1. snapshot: Grab a snapshot of portage-stable. Note that overalys are
not snapshotted.
2. stage1: Using a "seed" tarball as a build environment, build a
minimal root file system into a clean directory using ROOT=...
and USE=-* The restricted USE flags are key be small and avoid
circular dependencies.
3. stage2: Run portage-stable/scripts/bootstrap.sh
This rebuilds the toolchain. Probably not strictly necessary most of
the time but does super-duper-promise that the toolchain isn't linked
to or otherwise influenced by whatever was in the "seed" tarball.
4. stage3: Run emerge -e system to rebuild everything using the fresh
toolchain using the normal USE flags provided by the profile. This
will also pull in assorted base system packages that weren't included
in the minimal environment stage1 created.
5. stage4: Install any extra packages or other desired tweaks. For the
sdk we just install all the packages normally make_chroot.sh does.
