On Fri, Feb 17, 2023 at 12:43:01PM -0700, Sam Hartman wrote: > > I am not entirely convinced that using current rather than guest > tools for image building is an anti-pattern. You've been working on > filesystems for a long time; I've been working on various image > building projects since my first watchmaker project at MIT.
For what it's worth, I've been building test appliances[1] for the purposes of file system testing since 2013 (initially just for Qemu, but now for Cloud[2] environments as well as Android[3]). Admittedly, I haven't been doing this as long as you, but I'm not unfamiliar with building appliance images using debootstrap, and I've *always* built my KVM/Qemu images using a build chroot[4], including the mkfs and debootstrap steps. [1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/gen-image [2] https://thunk.org/gce-xfstests [3] https://thunk.org/android-xfstests [4] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot So I'm happy to talk to you off-line about best practices for building images, but this is something that I do *regularly*, since there are weekly updates from upstream xfstests. Thus, I have personal experience that using a build chroot for image creation really is *not* *that* *hard*. For that matter, when I'm doing test appliance development, I'm running regression tests[5] several times a day which build images in a chroot. [5] https://github.com/tytso/xfstests-bld/blob/master/selftests/appliance Everything is automated. No fuss, no muss, no dirty dishes. :-) Futher, it provides better build reproducibility, no matter who is building the image, and it also makes full GPL compliance (if you are publishing the test appliances) much, *much* easier --- I can provide an exhaustive list of all components (including mkfs.ext4!) and control scripts involved with the creation of the image. Cheers, - Ted
