Mailinglist Archive: opensuse-support (220 mails)

< Previous Next >
[opensuse-support] Re: After upgrading to 15.0, I find rpmsave files identical to the original
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
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
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

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.

< Previous Next >
Follow Ups