The pooled package carries the release bytes, which the existing digest check
covers, but it must not be the release file itself; assert the identity is
distinct so a link cannot come back unnoticed.
Every selected suite receives the whole release, so publication copied one image
per architecture per codename -- hundreds of megabytes each, several gigabytes on
the build host and again in the published tree.
Use --reflink=auto: filesystems that can share extents copy-on-write stop paying
for the duplication, and the pool entry stays a file of its own everywhere, which
a hardlink would not -- that would leave the published package and the verified
release sharing an inode, where a write through either path changes the other.
The two checksum passes around the verifier read as a duplicated walk; say what
the second one is for. Record which rpm versions reproduce the package identity
verify-release requires, so a build host outside that set is a known question
rather than a guess.
%_buildtime is not an rpm macro: built with it alone and no SOURCE_DATE_EPOCH,
rpm 4.14.3, 4.16.1.3 and 4.19.1.1 all stamped the current time. The build time
and build host the release verifier checks come from SOURCE_DATE_EPOCH with
use_source_date_epoch_as_buildtime, and from _buildhost -- both honoured on
every one of those versions and on rpm 6.0.2, where the package also builds
and verifies unchanged.
cmp guards the release manifest against changing during verification, which is
a --genesis-release concern; a legacy build never reaches it. Check for it with
the other release prerequisites instead of failing a plain build over a tool it
does not use.
Collection drops every xCAT-genesis-openembedded package once --genesis-release
is given, and the install that puts the verified ones back was skipped in dry
runs. A dry run therefore described a repository with no Genesis packages while
the real run published the whole set.
Report the release packages a real run would install and count them, so the
dry-run summary matches what the run would do.
A run with --genesis-release whose builders produced nothing must stop at the
collection guard rather than reach the deployable repository, so pin the exit
status, the message and the untouched deployment directory.
The Genesis release is installed from a verified directory instead of being
built here, so counting it before the "did anything build?" checks made those
checks unreachable with --genesis-release: a run whose builders had all failed
carried seven release packages past the guard, ran createrepo, and copied them
into the deployable per-EL tree before assert_required_deps stopped it, naming
the missing dependencies rather than the failed builds.
Assert on what the run collected first, then add the release. The source-RPM
warning was masked the same way and moves with it.
Vinícius Ferrão