On 1/11/23 11:21, Andrea Bolognani wrote:
On Wed, Jan 11, 2023 at 05:35:01PM +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 11, 2023 at 09:24:09AM -0800, Andrea Bolognani wrote:
>> Based on the fact that virtlogd is opt-out and virtlockd is opt-in,
>> can we leave the Requires=virtlogd.socket relationship alone and add
>> a dependency on libvirt-daemon-log to libvirt-daemon-driver-qemu,
>> while at the same time demoting the Requires=virtlockd.socket to a
>> Want and *not* adding a dependency on libvirt-daemon-lock?
>
> Yes, the virtlockd one is a bit inconsistent. Since we don't have
> it enabled by default, we don't need it as a Requires clause either.
>
> We need to fix the Fedora presets, since I notice we missed the
> virtlockd.socket / virtlogd.socket presets. This was harmless
> while a Requires existed. If we fix the presets, we can drop the
> virtlockd requires.
Sounds good!
My only concern is compatibility with existing Fedora releases. Will
the systemd preset update be rolled out to Fedora 36 and 37, or be
limited to Rawhide and future releases? We need to consider RHEL and
SUSE too.
AFAIK, there is nothing to consider for SUSE. None of the sockets/services are
enabled by default on openSUSE. And ensuring correct presets based on the
corresponding libvirt package structure should be easy in SLES.
Should we keep relationship with virtlockd.socket for the time
being,
turning it from a Requires to a Wants, and only drop it once we are
confident that the presets have been updated across the board?
Can't the 'Wants=' stay, regardless of presets?
FYI, I'm going to spin a V8 that splits this patch. Removing the libvirt-daemon
dependency from the secondary drivers will remain here. The hypervisor drivers
will be handled in a new patch, since they require additional tweaking.
Regards,
Jim