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

[Michael Biebl]

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.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20221005/b51a944e/attachment.sig>