You're further along than I assumed — I can see the whole setup: the bootstrap-x86_64 image is an LFS-style rootfs with your own x86_64-valhalla-linux-gnu triplet, and the local repo already has real packages in it (glibc 2.43, glibc-devel, cmake, jansson) built inside that image. So you're already in "stage 3" — the LFS image replaced the entire cross-toolchain dance. Here's the path from exactly where you stand, plus three mismatches I spotted that will bite you if not decided now.

Three things to fix first

1. main-x86_64.yml has the wrong name: field. It says name: bootstrap-x86_64 (copy-paste). Since image resolution keys off the profile's internal name, --profile main-x86_64 would silently build against the bootstrap image forever and the pivot would never actually happen. Change it to name: main-x86_64 and give it the full seed package list (right now it's just glibc, cmake).

2. Decide your libdir now: /usr/lib or /usr/lib64. Your LFS image is lib-flavored (/usr/lib, with /lib64 only for the loader), but apkg's %libdir% macro expands to {prefix}/lib64 on x86_64 — Solus-flavored. Every package you build with %CONFOPTS% installs its libraries to /usr/lib64, where your LFS toolchain doesn't look. You have two consistent options:

• ** Valhalla = lib** (recommended, matches your image): change %libdir% for x86_64 to {prefix}/lib in macros.rs. Pristine Solus recipes stay compatible because they reference %libdir% symbolically — you control what it expands to.
• Valhalla = lib64 (byte-level Solus parity): keep the macro, but then the bootstrap image needs /usr/lib64 in /etc/ld.so.conf, LDFLAGS=-L/usr/lib64, and note your builder's PKG_CONFIG_PATH only includes {prefix}/lib/pkgconfig — /usr/lib64/pkgconfig never gets searched, so pkgconfig() builddeps installed into the overlay won't be found. That's a real gap in build_env() if you go this way.

3. Triplet mismatch. %HOST% expands to x86_64-linux-gnu, and the --build=%HOST% I added to %CONFOPTS% will disagree with what your x86_64-valhalla-linux-gnu toolchain's config.guess detects. Usually harmless, occasionally causes autotools to mis-derive tool prefixes. Worth making the triplet configurable (profile or ApkgConfig field) so it says valhalla.

The plan from here

Phase A — fill the local repo inside bootstrap-x86_64. Continue what you started with glibc/cmake: build the system.base+system.devel equivalent from Solus recipes (adapted where needed), one wave at a time:

apkg-builder build <recipe>/package.yml --profile bootstrap-x86_64 --local
apkg-builder local add *.apkg && apkg-builder local index

A workable order after glibc: zlib → binutils → gcc (real one, replacing gcc-bootstrap) → make → ncurses → bash → coreutils → sed/grep/gawk/patch/findutils/diffutils → xz/zstd/bzip2 → file → m4/bison/flex → pkgconf → perl → python3 → autoconf/automake/libtool → util-linux → gettext → texinfo → fakeroot → baselayout. The baselayout package is where you encode the usr-merge symlinks, users/groups, and /etc skeleton.

Phase B — pivot off LFS. Once that list exists as .apkg files, fix the main profile's seed list and:

apkg-builder image build main-x86_64

This rootfs contains zero LFS bits — every file came from your own packages. This is the moment your distro is born; the LFS image becomes disposable.

Phase C — converge. Rebuild the same package set with --profile main-x86_64 --local, toolchain first, and rebuild glibc/binutils/gcc a second time inside an image refreshed from their own first rebuild. Use your --abi-report to compare generations — when a rebuild is functionally identical to its predecessor, you're self-hosting and the fixpoint is closed.

Phase D — build the world. Now pristine Solus recipes in toposorted builddeps order, refreshing the image (image build/image update) as components complete. Remember the eopkg convention: treat your base component as an implicit runtime dep of everything, and never declare toolchain packages in builddeps — the image guarantees them, exactly like solbuild.

The one orchestration piece still missing is a driver that walks an ordered manifest and does build → local add → local index → next, with resume support — that's what makes Phase A/C/D a background job instead of an evening of typing. Want me to fix the profile/libdir/PKG_CONFIG_PATH issues and build that driver?