Bug 984724

Summary: Source rpms may cause > 100% completion percentages in -h output
Product: [Fedora] Fedora Reporter: Ville Skyttä <ville.skytta>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 19CC: ffesti, jzeleny, novyjindrich, packaging-team-maint, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rpm-4.11.3-1.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-26 07:51:18 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 Ville Skyttä 2013-07-15 20:01:42 UTC
# rpm -q rpm
rpm-4.11.1-1.fc19.x86_64

# ls -1 device-mapper-persistent-data-0.2.1-2.fc19.*
device-mapper-persistent-data-0.2.1-2.fc19.src.rpm
device-mapper-persistent-data-0.2.1-2.fc19.x86_64.rpm

# rpm -Uvh device-mapper-persistent-data-0.2.1-2.fc19.* 2>/dev/null
Preparing...                          ################################# [100%]
Updating / installing...
   1:device-mapper-persistent-data-0.2################################# [100%]
   2:device-mapper-persistent-data-0.2################################# [200%]

Hmm, 200% complete, I thought 100% would be the max... maybe the srpm doesn't get counted initially but does when displaying the completion percentage.

Comment 1 Panu Matilainen 2013-08-21 11:48:10 UTC
Easily reproduced, probably been broken forever. The issue basically is that source package installation happens through a very different code-path from binary installation, and the counters disagree when both get executed within a single invokation.

Lets just say I'm far more tempted to make such mixed binary/source installation an error rather than fiddle with the counters. Mixed binary/source installation is more likely a mistake than intentional, and if nothing else banning it might discourage installing sources as root a little bit.

Comment 2 Panu Matilainen 2014-03-26 07:51:18 UTC
Fixed upstream now, sort of:
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=4098bfd7fa94c89f70c162c46fcd3627c282a102

Mixed binary+source installation now looks somewhat like this:

[root@localhost rpm]# ./rpm -Uvh /tmp/telnet-0.17-58.fc20.x86_64.rpm ~pmatilai/rpmbuild/SRPMS/telnet-*src.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:telnet-1:0.17-58.fc20            ################################# [100%]
Updating / installing...
   1:telnet-1:0.17-38.fc8             ################################# [100%]
   2:telnet-1:0.17-43.fc11            ################################# [100%]
   3:telnet-1:0.17-43.fc12            ################################# [100%]
[root@localhost rpm]#

Ie binaries and sources appear as separate operations, which they certainly are from rpm's POV, and progress no longer exceeds 100%. Its not "perfect" by any means but how many people actually install more than one src.rpm at a time anyway? :)

Given this is merely cosmetic, closing as UPSTREAM at this point. It'll make it to Fedora through updates at some point.

Comment 3 Fedora Update System 2014-09-08 06:56:19 UTC
rpm-4.11.3-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rpm-4.11.3-1.fc20

Comment 4 Fedora Update System 2014-09-16 07:49:51 UTC
rpm-4.11.3-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/rpm-4.11.3-1.fc19

Comment 5 Fedora Update System 2014-09-19 09:58:34 UTC
rpm-4.11.3-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2014-10-04 03:26:53 UTC
rpm-4.11.3-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.