[PATCH V5 10/11] spec: Remove libvirt-daemon dependency from hypervisor subpackages

Daniel P. Berrangé berrange at redhat.com
Mon Jan 9 14:25:44 UTC 2023


On Mon, Jan 09, 2023 at 05:44:51AM -0800, Andrea Bolognani wrote:
> On Mon, Jan 09, 2023 at 01:19:58PM +0000, Daniel P. Berrangé wrote:
> > On Mon, Jan 02, 2023 at 10:26:13AM -0500, Andrea Bolognani wrote:
> > >   * storage locking is not the default behavior and needs to be
> > >     turned on explicitly, so it's not a big deal if part of the setup
> > >     involves installing a couple extra packages in addition to
> > >     editing some configuration files, and everyone else gets a leaner
> > >     installation.
> >
> > Dropping libvirt-daemon-plugin-lockd breaks the upgrade path
> > for people using virtlockd, as nothing will pull in the
> > plugin for talking to virtlockd
> 
> libvirt-daemon still depends on libvirt-daemon-plugin-lockd. In the
> upgrade scenario, libvirt-daemon is already installed, so on upgrade
> libvirt-daemon-plugin-lockd will be automatically dragged in. It will
> only be skipped for new installations.

Opps, yes, you're right about upgrades being OK, only new installs
are affected.

I still th8ink that dropping the dep is wrong, becasue that is
defeating the purpose of 'libvirt-daemon-$HYPERVISOR' packages
aim todo:

  "installs every possible libvirt feature for the virtualization
   driver in question"

  https://libvirt.org/kbase/rpm-deployment.html#full-features-for-one-virt-driver

If you don't want all the features, then don't install that
package, pick the minimal install instead

  https://libvirt.org/kbase/rpm-deployment.html#minimal-features-for-one-virt-driver


> If you feel that the various libvirt-daemon-$hypervisor packages need
> to keep providing the same exact functionality over time, then yes,
> we can't drop or downgrade any of the dependencies. But, at the same
> time, we're potentially breaking consumers by taking away libvirtd...

Where the functionality still exists, the packages should continue
to provide it. The case of libvirtd is a bit special, as we're in
the process of phasing out its existance. That's not the cae for
virtlockd.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the libvir-list mailing list