15.01.2019 22:24, Andrei Borzenkov пишет:
14.01.2019 22:31, Carlos E. R. пишет:
I found these two:
Telcontar:~ # diff -s /etc/fonts/conf.d/10-rendering-options.conf.rpmsave /etc/fonts/conf.d/10-rendering-options.conf Files /etc/fonts/conf.d/10-rendering-options.conf.rpmsave and /etc/fonts/conf.d/10-rendering-options.conf are identical Telcontar:~ # diff -s /etc/fonts/conf.d/58-family-prefer-local.conf.rpmsave /etc/fonts/conf.d/58-family-prefer-local.conf Files /etc/fonts/conf.d/58-family-prefer-local.conf.rpmsave and /etc/fonts/conf.d/58-family-prefer-local.conf are identical Telcontar:~ #
If the new configuration file is the same as the old one,
a) Files are different from files in RPMDB because they are generated by scripts during installation. Files in RPMDB are of size 91 bytes. So from RPM point of view they are changed after installation.
b) RPM cannot directly compare files in old and new packages, it can only compare file digests in RPMDB and in new package. And they are different (more precisely they are using different algorithms so cannot be compared so assumed different). And neither digest matches content of on-disk file either.
bor@linux-99af:~/Downloads> rpm -q --dump -p fonts-config-20180430-7.6.1.noarch.rpm | fgrep conf.d/10-ren /etc/fonts/conf.d/10-rendering-options.conf 91 1545411859 39150c6aa26ca537c48a319685685695 0100644 root root 1 0 0 X bor@linux-99af:~/Downloads> rpm -q --dump -p fonts-config-20160921-lp150.2.3.noarch.rpm | fgrep conf.d/10-ren /etc/fonts/conf.d/10-rendering-options.conf 91 1519074400 f7faf868865e7f98b1f96c5bf33500d855337b4145ee66088796c09dc17e86db 0100644 root root 1 0 0 X bor@linux-99af:~/Downloads>
So RPM quite correctly preserves old version of %config file.
Further discussion whether it is possible to improve handling of such files should really go to opensuse-packaging.
And note that this happens only if old and new packages are using different digests. This should not happen in Leap 15 because RPMDB content will match updated package (files are the same, digests algorithms are the same) and I suspect we won't see SHA256 replaced by different algorithm by default soon so it will likely won't happen in Leap 15 successor either. IOW this is more or less corner case which hardly warrants time spent to fix it. Of course if you can come up with solution that is trivial to implement, by all means go ahead.