[pkg-go] Bug#1020691: debos should depend on systemd-resolved

[Christopher Obbard]

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