Seems like some recent rpm changes changed some feature which been working more than 20 years. Looks like install/upgrade source package which should only unpack src.rpm in build tree now opens rpm database in R/W mode. $ rpm -Uvh iozone-3.408-1.src.rpm warning: iozone-3.408-1.src.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) It breaks as well rpmfs in midnight commander: $ /usr/libexec/mc/extfs.d/rpm run /home/tkloczko/rpmbuild/SPECS/iozone-3.408-1.src.rpm INSTALL Installing "/home/tkloczko/rpmbuild/SPECS/iozone-3.408-1.src.rpm" error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) I'm sure that it was working about month ago on rawhide. $ rpm -q rpm rpm-4.13.0.1-3.fc26.x86_64
Just made another experiment trying to install src.rpm from root: [root@domek SPECS]# rpm -Uvh iozone-3.408-1.src.rpm warning: iozone-3.408-1.src.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY Preparing... ################################# [100%] Updating / installing... 1:iozone-3.408-1 warning: user builder does not exist - using root warning: user builder does not exist - using root warning: user builder does not exist - using root ################################# [100%] [root@domek SPECS]# rpm -q iozone iozone-3.408-1.i686 [root@domek SPECS]# rpm -ql iozone iozone-make.patch iozone.spec iozone3_408.tar [root@domek SPECS]# rpm -V iozone .....U... iozone-make.patch .....U... s iozone.spec .....U... iozone3_408.tar [root@domek SPECS]# cd [root@domek ~]# rpm -V iozone missing iozone-make.patch missing s iozone.spec missing iozone3_408.tar So looks like now instead unpacking src.rpm it registers it in rpm database with list of files archived in src.rpm
Well that's strange, it works just fine over here. Two things: - Can you reproduce it with other src.rpm's than the iozone one? - Please give me a pointer to the exact iozone src.rpm used here
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I've spend a bit more time investigating this issue and I found the cause. $ rpm -qp --qf "%{RPMVERSION}\n" iozone-3.408-1.src.rpm warning: iozone-3.408-1.src.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY 5.4.10 Looks like rpm 4.13.x has a problem with handling src.rpm packages generated using rpm 5.4.x and it does not recognizes those packages as src.rpm packages or it is bug in upcoming rpm 5.x which puts wrong package metadata. You can find samples of src.rpm packages generated using rpm 5.x at ftp://ftp.icm.edu.pl/pub/Linux/dist/pld-linux/dists/3.0/PLD/SRPMS/
Right, actually suspected that much. But this doesn't make much sense: the logic by which source and binary rpms are distinguished hasn't changed since 2009 when it was tweaked for the very reason of rpm 5 compatibility. And the iozone package has build date from 2012. Also I can't reproduce on F25 but then you're on F26, so that leaves something like a gcc-caused bug, BUT I can't reproduce on F26 either. Looking a bit more, I *can* reproduce with recent packages such as this: ftp://ftp.icm.edu.pl/pub/Linux/dist/pld-linux/dists/3.0/PLD/SRPMS/RPMS/ald-0.1.7-4.src.rpm So rpm 5 has broken something, it's theirs to fix too.
FTR: I've informed rpm5 developers about this issue. http://rpm5.org/cvs/tktview?tn=99
Sigh. My statement about it not being reproducible with iozone was incorrect, it indeed is. So apparentely PLD has been building packages that are incompatible with rpm.org for several years, this is not a new thing at all but the same old differences between src.rpm identification.