On Thu, 2022-10-06 at 10:11 +0700, Arnaud Rebillout wrote: > > On 05/10/2022 22:06, Michael Biebl wrote: > > I think if you want to assemble a root/usr fs where you don't want > > do > > "disturb" the host system, I'd use a debootstrapped chroot but not > > the > > host fs. > > I think the original reason for fakemachine to exist was to build OS > images from within containers. At first it doesn't sound like a great > idea, because usually there's not enough capabilities in the > container > for that (ie. no access to the loop device). But systems like Jenkins > or > GitLab CI drop you in a container, you have no choice. So fakemachine > came as a solution / workaround to spawn a VM from within a container > (according that you have access to /dev/kvm), and then from within > the > VM you can build an OS image. > > Hence this weird approach of "faking a machine", ie. creating a VM by > reusing bits from the host filesystem. To say it again: if you're > already within an environment that has been setup for the job (chroot > or > container), no need to debootstrap a chroot again, let's just make > sure > this environment has everything needed, and re-use it for the VM. > That's > the approach of fakemachine, as I understand it. > > And so, for this use-case when fakemachine is used from within a > chroot/container, I must say that the systemd-resolved split is not > really problematic: all it takes is to add systemd-resolved to the > list > of packages to install in the chroot/container. > > The issue is for people installing fakemachine on their own machine. > So > far it worked great (I've been using it a lot to build OS images). > Now > it doesn't anymore. So either I install systemd-resolved, either I > start > a chroot and run fakemachine from there. It doesn't work "out of the > box" anymore, if you want. > > > > Say you want to install apache2 in your fakemachine managed VM, > > this > > would also start it on the host system, or not? > > Yes, but this comparison is not really relevant here. systemd- > resolved > is needed for the VM to have a functional network, so it's really a > prerequisite for a functional VM, regardless of what users want to do > with it. Hence the question of whether it should become a Depends for > the fakemachine package. > > While apache2 will never be a Depend of fakemachine in any case, and > if > users have a need for a particular need for that, it's in their hand > to > decide how to do it. > > Maybe fakemachine is more or less a VM counterpart of "systemd-nspawn > -D > / -xb" (systemd-nspawn(1), example 6)? > > I hope that I clarified a few points here. Would be nice to hear more > from fakemachine maintainers. > > Best regards, >
I have proposed[1] to check if systemd-resolved is available at runtime, to at least let users know *why* name resolution doesn't work inside their fakemachine over letting the user debugging it themselves. Perhaps we should add systemd-resolved to Suggests in debos/fakemachine? Adding it as a Depends/Recommends would break users who have some other package on their machine handling name resolution. @Arnaud, how does that sound? [1]: https://github.com/go-debos/fakemachine/pull/115 _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
