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 just sets the code file size to the var file size, so it gets
zero-padding without having to pipe commands together.
From: David Michael <david.michael@coreos.com>
[Rebased]
Signed-off-by: Geoff Levand <geoff@infradead.org>
And default to git instead of rsync.
git has no rate limiting and will generally be quicker after the first
run.
This does leave a bit of extra data in your local portage-stable `.git`
directory, but it doesn't seem unreasonable to me.
Note: this means we lose the "ChangeLog" file. In the rsync
repositories, that file has been generated by egencache, but the git
repository never has it checked in.
The motivation behind retaining this backwards compatibility, at least
now, is that it's actually non-trivial to revert these code changes for
a given release.
The `sign.sh` changes can easily be changed, but the `core_sign_update`
code is included in the update-specific "au_zip" file. Replacing that is
a little more fiddly.
Since it's possible we'll still want to revert to the previous signing
behavior, make it so the update payload (namely core_sign_update) should
work both under the previous `sign.sh` script, and when using the new
one.
