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

[Luca Boccassi]

On Wed, 5 Oct 2022 at 17:06, Michael Biebl <biebl at debian.org> wrote:
>
> Am 05.10.22 um 16:08 schrieb Arnaud Rebillout:
> > On 05/10/2022 16:58, Christopher Obbard wrote:
> >> Hi Arnaud,
> >>
> >> Thanks for shedding the extra light. This is not a nice bug !
> >>
> >> I think we should ask the systemd maintainer if they'd accept a patch
> >> to make the enabling of systemd-resolved service a manual operation, or
> >> at least to split the binary into a separate package, something like
> >> systemd-standalone-resolved ?
> >
> >
> > Dear systemd maintainers,
> >
> > the packages fakemachine & debos (which uses fakemachine) are facing an
> > issue now that systemd-resolved was split in a separate package.
> >
> > For the background: fakemachine is a program that spawns a QEMU VM that
> > "mimics" the host. It does so mainly by mounting /usr from the host into
> > the VM, plus a few other bits from here and there. For the network to
> > work in the VM, it relies on systemd-networkd and systemd-resolved.
> > These programs need to be present on the host, so that they are
> > available in the VM.
> >
> > For more details, you can just run "fakemachine" in a shell, then "ps
> > fax | grep qemu" in another shell: you will see how fakemachine uses qemu.
> >
> > So far, the package fakemachine Depends on systemd, and that was enough.
> > Now with the split, and since we need systemd-resolved, we should make
> > fakemachine Depend on systemd-resolved as well. However, and if I
> > understand properly, installing systemd-resolved also *enables* it. A
> > user installing the package is saying: I want name resolution to be done
> > by systemd-resolved. Therefore it's not really suitable to put it in a
> > Depend or a Recommend. fakemachine only needs the code from
> > systemd-resolved (lib and binary, I suppose), but it definitely doesn't
> > want to enable it: this decision belongs to the user.
> >
> > Does that make sense so far?
>
> Not really, tbh. 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.
> Say you want to install apache2 in your fakemachine managed VM, this
> would also start it on the host system, or not?
> I don't know why fakemachine does it this way and it's possible I'm
> missing something, but this approache feels "weird" to me, for the lack
> of a better word.

Indeed, and the approach should be the opposite - if you want the
binary but not to run it, then for that special case you should script
it to disable it. Enablement is done via postinst.

The semantics that we _want_ are that installing the package means
"use this as my resolver", i.e., the default is very much
intentionally that installing it also enables it, so that for the
supported case there's no manual step to do, it "just works" out of
the box. This is the approach that upstream recommends.

Kind regards,
Luca Boccassi