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

[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?

I don't know how to solve best this situation. Maybe the the lib and 
binaries could go back into the systemd package, leaving only the 
"enablement" part in systemd-resolved?

Thanks!

-- 
Arnaud Rebillout / Offensive Security / Kali Linux Developer