On Thu, 2020-12-03 at 17:39 +0100, Michal Privoznik wrote:
On 10/26/20 10:21 AM, Nikolay Shirokovskiy wrote:
-cp %{_datadir}/libvirt/nwfilter/*.xml %{_sysconfdir}/libvirt/nwfilter/ +# keep existing filters uuid on update +for dfile in %{_datadir}/libvirt/nwfilter/*.xml; do + sfile=%{_sysconfdir}/libvirt/nwfilter/`basename $dfile` + if [ -f "$sfile" ]; then + uuidstr=`sed -n '/<uuid>.*<\/uuid>/p' "$sfile"` + if [ ! -z "$uuidstr" ]; then + sed -e "s,<filter .*>,&\n$uuidstr," "$dfile" > "$sfile" + continue + fi + fi + cp "$dfile" "$sfile" +done
I wonder if we should treat these .xml files as config files. I mean, they can be changed by user and if they have been we should not touch them at update no matter what. But if they haven't, then we should replace them because they may contain new, better rules.
I've read spec file documentation here and it looks like %config(noreplace) is doing just that:
https://rpm-packaging-guide.github.io/#more-on-macros
Would that solve the issue?
I think treating them as configuration files is exactly the opposite of what we want to do, because they contain generated data (the UUID) and so they will *always* be different from what was included in the package. I believe the only sane way to deal with them is mirror what we do for the default network, and just leave the files in /etc alone if they already exist: the user might miss out on improvements, but that's still preferable to potentially wipe out local changes. -- Andrea Bolognani / Red Hat / Virtualization