- it shouldn't be possible to set the SDK version to the same as the new
tag's version. The SDK must always be a previous build.
- don't fail if there isn't any old manifests to git rm.
There are ways to improve, it'd be sexy if it was truly safe and we
could throw around annoying terms like idempotent to make this kind of
sequence just work but doesn't yet: tag_release; tag_release --push
When calling update_chroot with --usepkg --nogetbinpkg the default
emerge command line will force binary packages for the toolchain but if
the packages are not available locally building via crossdev is
required. Since the crossdev bootstrap process rebuilds the toolchain a
couple times with different use flags if binary packages are forced the
second stages gets skipped resulting in a broken gcc and glibc install.
Instead of gating only on --usepkg depend on both flags as a pair. This
keeps setup_board's behavior a little closer to build_packages. The
buildbot is using --nogetbinpkg to avoid pulling in existing packages
built by the SDK but setup_board is causing some to be pulled in anyway.
This makes it possible to toggle parallel_emerge just as other scripts
do. In other scripts update the help string to be more specific, the
--jobs option can be used to control parallelism.
Although it didn't seem to be causing any bugs the global variables in
toolchain_util conflicted with some names used elsewhere. Clean that up
by adding an S to the array names that didn't already have one.
When calling update_chroot with --nousepkg it is silly to always force a
rebuild of the cross toolchain. Change the test to work regardless of
whether binary packages are enabled by checking if anything needs to be
built from source.
A new board build root always starts with an empty package cache so if
binary packages are enabled downloading is required. The distinction can
be useful for passing to update_chroot since its cache isn't impacted so
the flag remains, just among the less used hidden ones.
Now this code can be shared with setup_board. Only required if
setup_board is called with --nousepkg which is rare to never but feels
like the correct thing to do. Alternatively setup_board could always
use binary packages (as it basically does now).
These excludes are used in images and I want to use the same checking
code as images do so the build root needs to behave the same way.
This is temporary as I'll switch to installing libc via emerge soon.
Instead of handling toolchain packages in make_chroot and telling
update_chroot to skip the toolchains just depend on update_chroot to do
it properly. Reduces our code duplication by a tiny but worthwhile bit.
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.
The current logic for downloading SDK tarballs is in cros_sdk and
written in python which isn't super convenient for re-using in the rest
of our shell scripts. This is a start of rewriting that logic into a
re-usable library but does not yet replace the functionality in cros_sdk.
A number of places refer to these paths and that number is going to
grow. Since the standard pattern is to use environment variables for
commonly used paths it is time to add ones for these:
REPO_CACHE_DIR
REPO_MANIFESTS_DIR
This scheme only works robustly with kexec. Until the happy day that
kexec is supported on Xen (or when Xen is dead, long live Xen!) we
shouldn't bother trying. This allows us to use kernel modules again.
Currently we don't have a good way to upload packages from different
jobs to the same location. The 'Packages' index file is only generated
locally so the second upload would always win.
