Drop obsolete comments about how Catalyst stage 1 is built

Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
This commit is contained in:
James Le Cuirot 2024-08-01 10:18:06 +01:00
parent 7d85ee75da
commit 44223cbbe0
No known key found for this signature in database
GPG Key ID: 1226415D00DD3137

View File

@ -87,37 +87,6 @@ mkdir -p "${ROOT_OVERLAY}/tmp"
chmod 1777 "${ROOT_OVERLAY}/tmp"
cp "${BUILD_LIBRARY_DIR}/toolchain_util.sh" "${ROOT_OVERLAY}/tmp"
# Stage 1 uses "known-good" ebuilds (from both coreos-overlay and portage-stable)
# to build a minimal toolchain (USE="-*") for stage 1.
#
# No package updates must happen in stage 1, so we use the portage-stable and
# coreos-overlay paths included with the current SDK (from the SDK chroot's
# /var/gentoo/repos/). "Current SDK" refers to the SDK we entered with
# 'cork enter', i.e. the SDK we run ./bootstrap_sdk in.
#
# Using ebuilds from the above mentioned sources will ensure that stage 1 builds
# a stage 3 from known-good ebuild versions - the same ebuild versions
# that were used to build the very SDK we run ./bootstrap_sdk in.
#
# DANGER ZONE
#
# Stage 1 lacks proper isolation and will link all packages built for
# stage 3 against its own seed libraries ("/" in the catalyst chroot) instead of against libraries
# installed into the FS root of the stage 3 seed ("/tmp/stage1root" in the catalyst chroot).
# This is why we must prevent any updated package ebuilds to "leak" into stage 1, hence we use
# "known good" ebuild repo versions outlined above.
#
# In special circumstances it may be required to circumvent this and use custom paths
# for either (or both) portage and overlay. The command line options
# --stage1-portage-path and --stage1-overlay-path may be used to specify
# a repo path known to work for stage1. In that case the stage1 seed (i.e. the seed SDK)
# will be updated prior to starting to build stage 3.
# NOTE that this should never be used to introduce library updates in stage 1. All binaries
# produced in stage 1 are linked against libraries in the seed tarball, NOT libraries produced
# by stage 1. Therefore, these binaries will cease to work in stage 3 when linked against
# outdated "seed tarball" libraries which have been updated to newer versions in stage 1.
catalyst_build
if [[ "$STAGES" =~ stage4 ]]; then