[libvirt PATCH v2] spec: Merge -bash-completion and -admin into -client

[Andrea Bolognani]

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.

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.

What about the systemtap probes? Do they belong in -client, or maybe
they should go into -libs? I'm not familiar with their use.

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.

-- 
Andrea Bolognani / Red Hat / Virtualization