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

Daniel P. Berrangé berrange at redhat.com
Mon Jan 9 16:56:39 UTC 2023


On Mon, Jan 09, 2023 at 09:49:04AM -0700, Jim Fehlig wrote:
> On 1/9/23 07:54, Andrea Bolognani wrote:
> > On Mon, Jan 09, 2023 at 02:25:44PM +0000, Daniel P. Berrangé wrote:
> > > 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.
> > 
> > Okay, the fact that we're explicitly documenting these packages as
> > the "every possible feature for the driver" option means that I have
> > no choice but to agree with you :)
> > 
> > Jim, can you please respin while reverting these changes that I had
> > suggested? Sorry :(
> 
> No problem, will send a V7. BTW, what is the list preference for suppresscc?
> I've been meaning to ask that after the past several versions, as I watch
> git send-email spam the R-B. My global .gitconfig only suppresses 'self'.

My position is that contributors shouldn't worry about that either way.
We need to be friendly to contributors and not complain about whether
they do or don't CC previous reviewers. Undocumented project specific
"rules" about how to send email are one of the many trapdoors for email
based workflow.

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