[PATCH 0/7] spec: Decompose the daemon subpackage

Daniel P. Berrangé berrange at redhat.com
Tue Dec 13 09:18:11 UTC 2022


On Tue, Dec 13, 2022 at 01:15:26AM -0800, Andrea Bolognani wrote:
> On Mon, Dec 12, 2022 at 03:19:31PM -0700, Jim Fehlig wrote:
> > On 12/11/22 10:46, Andrea Bolognani wrote:
> > > I think we should just have a libvirt-daemon-common package that
> > > includes what you currently have put into the libvirt-daemon-client
> > > package plus these files, and have all hypervisor drivers depend on
> > > it directly.
> >
> > Taking a cue from the storage driver, I called it libvirt-daemon-core
> > (patches 4-6) in the original RFC
> >
> > https://listman.redhat.com/archives/libvir-list/2022-November/235924.html
> >
> > But I'm fine with libvirt-daemon-common too :-). I'll change it in V2 while
> > addressing the other comments.
> 
> I wasn't unable to find a document that contains a formal policy on
> this, but my understanding is that foo-core is a stripped-down
> version of foo that only contains the very basic functionality, while
> foo-common is stuff needed by foo and doesn't do anything useful on
> its own.
> 
> Based on this reading, libvirt-daemon-driver-storage-core and
> libvirt-daemon-common are the appropriate names for the respective
> packages.
> 
> Anyone with actual RPM packaging experience, please call me out if
> I'm spouting nonsense :)

Once you go beyond -devel, -docs and -libs, sub-RPM naming is almost[1]
entirely arbitrary, and at the discretion of the package maintainer 

With regards,
Daniel

[1] caveat: programming language specific guidelines may apply
-- 
|: 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