qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Christian Ehrhardt]

On Thu, Aug 20, 2020 at 5:15 PM Mark Mielke <mark.mielke at gmail.com> wrote:
>
> On Thu, Aug 20, 2020 at 8:55 AM Christian Ehrhardt <christian.ehrhardt at canonical.com> wrote:
>>
>> On Thu, Aug 20, 2020 at 12:43 PM Martin Wilck <mwilck at suse.com> wrote:
>> > The simplest approach is to touch the qemu binaries. We discussed this
>> > already. It has the drawback that it makes "rpm -V" complain about
>> > wrong timestamps. It might also confuse backup software. Still, it
>> > might be a viable short-term workaround if nothing else is available.
>>
>> Qemu already allows to save modules in /var/run/qemu/ [1] to better handle
>> module upgrades which is already used in Debian and Ubuntu to avoid
>> late module load errors after upgrades.
>>
>> This was meant for upgrades, but if libvirt would define a known path in
>> there like /var/run/qemu/last_packaging_change the packages could easily
>> touch it on any install/remove/update as Daniel suggested and libvirt could
>> check this path like it does with the date of the qemu binary already.
>>
>> [1]: https://github.com/qemu/qemu/commit/bd83c861c0628a64997b7bd95c3bcc2e916baf2e
>
>
> Earlier in this thread - I think one or two of us had asked about the timestamp on the directory that contains the modules.
>
> I'm wondering if a "last_packaging_change" provides any value over and above the timestamp of the directory itself? Wouldn't the directory be best - as it would work automatically for both distro packaging as well as custom installs?

Sure, if
- "list of files in module dir"
- "stat dates of files in module dir"
would be checked by libvirt that would also be a no-op for packaging
and thereby land faster.

But I guess there were reasons against it in the discussion before?

> --
> Mark Mielke <mark.mielke at gmail.com>
>


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd