On Mon, Apr 19, 2021 at 05:42:01PM +0200, Andrea Bolognani wrote:
On Mon, 2021-04-19 at 11:45 +0200, Michal Privoznik wrote:
On 4/15/21 2:52 PM, Andrea Bolognani wrote:
the latter is also very small and, just like virsh, is something that you likely want to have available on any virtualization host to help with management and debugging tasks.
Exactly! Host, not client. Not every virt client is virt host too. Also, what's stopping management from installing libvirt-admin among with other RPMs? It's tiny, as you say. But I think I've expressed my concern enough.
Okay, let's not have virt-admin as part of -client then. Can we at least have it in -daemon as opposed to its own package? And while we're at it, we can move there also the other commands we agreed are probably not a good fit for -client.
virt-xml-validate just performs validation on the input XML, so having it in -client seems reasonable; on slighly closer inspection, virt-pki-validate can validate not only the server-side PKI situation but also the client-side one, so again -client is probably the most sensible home for it.
Yep, the RNGs are shipped with the library, so server can use tem already.
virt-host-validate is intended for the hypervisor host, so we can move it to -daemon; libvirt-guests should go there too, because it should live where the daemon does.
virt-host-validate clearly is daemon only. libvirt-guests is a little odd because in theory it doesn't depend on the daemon - it can work with stateless drivers. IIRC thats why it is in the clients package. I'm sceptical that anyone will ever even think about using the libvirt-guests script to automate startup/shutdown of VMware/Hyperv/Etc guests though.
What about the systemtap probes? Do they belong in -client, or maybe they should go into -libs? I'm not familiar with their use.
Probes can be compiled into pretty much any binary artifact - daemon, virsh, libvirt.so, driver modules. -libs is the common place to all of those.
On Mon, 2021-04-19 at 11:45 +0200, Michal Privoznik wrote:
On 4/15/21 2:52 PM, Andrea Bolognani wrote:
The former is ridiculously tiny and doesn't have any use on its own, so it hardly warrants the overhead of an additional package;
The idea was, that if you'd install virt-admin only, you would have bash completion too, hence a separate package.
On Mon, 2021-04-19 at 10:57 +0100, Daniel P. Berrangé wrote:
Per discussion on the previous version though, we better to have installed any time the daemon is installed and so if we do that it means we also want the bash completion separate from the client.
I would really like to get rid of the -bash-completion package.
$ rpm -ql libvirt-bash-completion /usr/share/bash-completion/completions/vsh $ du -sh /usr/share/bash-completion/completions/vsh 4.0K /usr/share/bash-completion/completions/vsh $ du -sh .../libvirt-bash-completion-7.2.0-1.fc32.x86_64.rpm 8.0K .../libvirt-bash-completion-7.2.0-1.fc32.x86_64.rpm
The completion file itself uses as much disk space as the RPM metadata for it. With that in mind, can we just install the file twice instead of having a single file with two additional symlinks pointing to it?
We could also turn it into a .in file so that instead of
# # virsh & virt-admin completion command #
_vsh_complete() { # ... } && complete -o default -o filenames -F _vsh_complete virsh && complete -o default -o filenames -F _vsh_complete virt-admin
the installed file for each command looks like
# # @cmd@ completion command #
_vsh_complete() { # ... } && complete -o default -o filenames -F _vsh_complete @cmd@
Basically, if we can't avoid the overhead of duplication altogether, I'd rather pay it on the filesystem than in the RPM database, where it's felt over and over again when dowloading repodata and when performing package management.
I think this worrying about micro-optimizing a problem that doesn't really have any real world impact. 8k is lost in the noise of an RPM transaction. 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 :|