Bug 1427287

Summary: rpm -Ufh <package>.src.rpm no longer unpacks source package from non-root
Product: [Fedora] Fedora Reporter: Tomasz Kłoczko <kloczko.tomasz>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: low    
Version: 26CC: ignatenko, kardos.lubos, kloczko.tomasz, packaging-team-maint, pknirsch, pmatilai, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-02 05:28:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomasz Kłoczko 2017-02-27 19:26:35 UTC
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

Comment 1 Tomasz Kłoczko 2017-02-27 19:29:56 UTC
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

Comment 2 Panu Matilainen 2017-02-28 08:06:20 UTC
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

Comment 3 Fedora End Of Life 2017-02-28 12:27:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 4 Tomasz Kłoczko 2017-03-01 14:46:36 UTC
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/

Comment 5 Panu Matilainen 2017-03-02 05:28:20 UTC
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.

Comment 6 Tomasz Kłoczko 2017-03-02 10:48:17 UTC
FTR: I've informed rpm5 developers about this issue.

http://rpm5.org/cvs/tktview?tn=99

Comment 7 Panu Matilainen 2017-03-02 11:03:39 UTC
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.