[PATCH V4 06/11] spec: Move common files and dependencies to libvirt-daemon-common

[Jim Fehlig]

On 1/2/23 07:53, Andrea Bolognani wrote:
> On Fri, Dec 23, 2022 at 10:57:34AM -0700, Jim Fehlig wrote:
>> On 12/23/22 03:52, Andrea Bolognani wrote:
>>> One more thing. After your changes, libvirt-daemon still has
>>>
>>>     # netcat is needed on the server side so that clients that have
>>>     # libvirt < 6.9.0 can connect, but newer versions will prefer
>>>     # virt-ssh-helper. Making this a Recommends means that it gets
>>>     # installed by default, but can still be removed if compatibility
>>>     # with old clients is not required
>>>     Recommends: /usr/bin/nc
>>>
>>> I think this should be moved to libvirt-daemon-common too, since
>>> modular daemons were introduced before virt-ssh-helper and so it's
>>> possible that old clients might try to connect to a modularized
>>> deployment, which will fail if nc is not available.
>>
>> Hmm, shouldn't it be libvirt-daemon-proxy? Remote clients don't connect to
>> the modular daemons directly, only through virtproxyd right?
> 
> Remote clients can connect to modular daemons directly as long as
> virt-ssh-helper is available on the server side. As a fallback, nc
> will be used and the connection will go through virtproxyd.
> 
> So yeah, nc will only be used when virtproxyd is involved, and so it
> makes sense to move the Recommends to that package instead of
> libvirt-daemon-common.
> 
> 
> Based on the above, however, I wonder if we should have at least a
> weak dependency on libvirt-daemon-proxy for libvirt-daemon-kvm and
> friends? As things are right now, clients that are more than ~2 years
> old will not be able to connect to the server unless the admin
> manually installs libvirt-daemon-proxy. Are we okay with that?

More specifically, clients prior to commit 3e9b561139 right? I.e., clients using 
libvirt 7.4.0 and older. I lean towards the weak dependency but don't have a 
strong opinion :-).

Regards,
Jim