Re: qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?
On Thu, Aug 20, 2020 at 2:01 PM Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
IIUC, Mark's point is that an RPM update won't replace the
file in-placec.
It will write out a new temporary file and then rename over the top of the
old file, which should trigger an update on the directory mtime.
Yep, correct.
Not sure what a "make install" will do with QEMU, but since
QEMU is about
to switch to meson, we might get lucky in having the same temp+rename
behaviour.
I think this is the relevant section of the Makefile:
ifneq ($(CONFIG_MODULES),)
$(INSTALL_DIR) "$(DESTDIR)$(qemu_moddir)"
for s in $(modules-m:.mo=$(DSOSUF)); do \
t="$(DESTDIR)$(qemu_moddir)/$$(echo $$s | tr / -)"; \
$(INSTALL_LIB) $$s "$$t"; \
test -z "$(STRIP)" || $(STRIP) "$$t"; \
done
endif
The INSTALL_LIB is detected by configure, and will normally be:
config-host.mak:INSTALL_LIB=install -c -m 0644
You can see here that "install" results in a new inode, which indicates a
new file:
$ cd /tmp
$ install -c -m 0644 /etc/motd motd_temp
$ ls -li motd_temp
*3544372* -rw-r--r-- 1 mark mark 0 Aug 20 17:25 motd_temp
$ install -c -m 0644 /etc/motd motd_temp
$ ls -li motd_temp
*3561572* -rw-r--r-- 1 mark mark 0 Aug 20 17:25 motd_temp
Once upon a time, this wasn't done - and the consequence is that things
like "make install" would break running programs with various undefined
behaviour. Now it is done "correctly" for so long, that people may have
forgotten the old days. :-)
--
Mark Mielke <mark.mielke(a)gmail.com>
Attachments:
- attachment.html (text/html — 2.6 KB)