We handle Go differently than Gentoo, so our 1.8.4 package includes
the same security fixes. When all packages are built with Go 1.9,
the older Go packages shouldn't be installed anymore, so this line
can be dropped.
This omits the toolchain packages' version-pinning flag for the
binutils package while it is being upgraded. It also removes older
versions installed in parallel that cause unwanted rebuilds.
When stable has the upgraded version, this can be reverted.
This includes the source package of all torcx packages that are
installed on disk, including cases where multiple versions of the
same package are available.
Per the comment there, they were implemented in a broken fashion.
This leaves the door open for using them in the future, but in the
meanwhile simply uses the sha512sum as the digest (which solves the
immediate issue).
This moves the default symlinking logic into build image as well.
This assumes that a torcx store is available locally with all images
referenced in the torcx manifest.
This is accomplished with a highly-indented double-for-loop, but I think
it's still decently readable.
This also moves the 'torcx' prefixing logic over to the torcx upload
root introduced in the release util library.
It also corrects a bug in how the source package was being determined.
Torcx is special in that it wishes to be uploaded under a prefixed
directory (torcx), typically wishes to be downloaded from there, but
ultimately wants to be downloaded from a location without that prefix.
In fact, I expect during a normal release process, it will be uploaded
with that prefix to the build bucket, copied without that prefix to the
final bucket (during pre-release), and then finally downloaded without
the prefix.
I think this set of variables ends up being the cleanest way to
represent this complexity.
This modifies the `build_torcx_store` script to produce a manifest and
cas-like structure of packages referenced by that manifest.
It also removes the symlink creation logic (which will be re-added in
build_image in coming commits).
The concept of "extra packages", which are referenced in the manifest,
but aren't installed in the rootfs, is also introduced.
Since the logic of what to include in the rootfs is also extracted into
build_image, supporting these "extra packages" isn't very complicated
for this file.
This seems to fix the ccache permission issues `update_chroot` hits
while building ninja.
The erroneous files were created as root:portage, so a umask of 002
should let other portage group members share them, which seems entirely
reasonable.
