Bug 484603 - debuginfo-install downloads packages already installed resulting in waste of time and bandwidth
debuginfo-install downloads packages already installed resulting in waste of ...
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-08 17:34 EST by Jaroslav Franek
Modified: 2014-01-21 18:08 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-12 14:52:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debuginfo-install console log (10.91 KB, application/x-gzip)
2009-02-08 17:34 EST, Jaroslav Franek
no flags Details
console log of actions that lead to the issue (4.89 KB, application/x-gzip)
2009-02-09 13:54 EST, Jaroslav Franek
no flags Details

  None (edit)
Description Jaroslav Franek 2009-02-08 17:34:09 EST
Created attachment 331255 [details]
debuginfo-install console log

Description of problem:

When upgrading debuginfo packages I noticed that debuginfo-install utility downloads not only the updates but also the already installed debuginfo packages. Then it simply discards the useless downloads. With the total download of 1.1 GiB it was a lot of waste.

This always happens when I play with updates-testing. I like to crash the software, well not really :-), but it happens to me often, so I need to update debuginfo from time to time.

Version-Release number of selected component (if applicable):

How reproducible:
Easy, see the steps below. I guess it will be the same with any package as long as there was an upgrade from updates-testing or any other repo that is not enabled by default.

Steps to Reproduce:

1. Say you have kde 4.1.4 installed.

2. Install debuginfo via
# debuginfo-install kde*
Now you have e.g.
$ rpm -qa | grep kdepim-debuginfo

3. Upgrade kde to 4.2 from upgrades-testing
# yum --enablerepo=update-testing update kde*
Probably restart is a necessary for kde 4.2

4. Now try to update debuginfo
# debuginfo-install --enablerepo=update-testing kde*

Actual results:

Many already installed packages are downloaded and discarded afterwards. The goal is achieved but at twice the price (of time and bandwidth).

Full console log attached. But see the interesting snippets (I chose the biggest package as an example):

1. Dependencies resolved:
 kdepim-debuginfo            i386 6:4.1.4-1.fc10                updates-debuginfo                105 M 
 kdepim-debuginfo            i386 6:4.2.0-2.fc10                updates-testing-debuginfo        112 M 

2. Downloading Packages:
(110/111): kdepim-debuginfo-4.1.4-1.fc10.i386.rpm                               | 105 MB     01:34     
(111/111): kdepim-debuginfo-4.2.0-2.fc10.i386.rpm                               | 112 MB     01:32     
Total                                                                  1.2 MB/s | 1.1 GB     15:53     

3. Running Transaction
  Updating       : kdepim-debuginfo                                                             37/128 
  Cleanup        : kdepim-debuginfo                                                            115/128 

4. Installed:
  kdepim-debuginfo.i386 6:4.1.4-1.fc10                                                                 
  kdepim-debuginfo.i386 6:4.2.0-2.fc10

5. rpm -qa | grep kdepim-debuginfo

Expected results:
Already installed packages are not downloaded, e.g.
kdepim-debuginfo.i386 6:4.1.4-1.fc10 is not downloaded.
Actually it was not installed as stated in point 4. but rather cleaned up.

Additional info:
debuginfo-install is said to find the respective packages by taking the name of nondebug package and adding -debuginfo to it. When using updates-testing, there can be two instances of the *-debuginfo packages: the one from fedora/updates repo and another one from updates-testing. My guess is that the debuginfo-install does not check that. It simply takes all matching debuginfo packages (e.g. kdepims-debuginfo-*.rpm) and set them for download and install. I would expect only those matching the latest versions (of kde in my case) installed will be downloaded and updated. I also miss the equivalent of update for debuginfo - update all already installed debuginfo packages.
Comment 1 James Antill 2009-02-09 01:40:15 EST
what does "yum list kdepim" say?
Comment 2 Jaroslav Franek 2009-02-09 03:40:06 EST
[root@localhost ~]# yum list kdepim
Loaded plugins: refresh-packagekit
Installed Packages
kdepim.x86_64       6:4.2.0-2.fc10      installed
Comment 3 James Antill 2009-02-09 11:08:01 EST
I can't reproduce this on Fedora 10.x86_64.

Can you post the output from a "debuginfo-install -d 9 kdepim"?
Comment 4 Jaroslav Franek 2009-02-09 13:54:47 EST
Created attachment 331344 [details]
console log of actions that lead to the issue

I can't either. On my x86_64 F10 the update seems to be OK. Strange. Well, the original report was from my i386 F10. I already updated kde*, but I can replicate the issue with ease on any almost package in updates-testing.

This time I chose my victim to be xsane. This is a list of commands I used. 

#  rpm -qa | grep xsane
#  debuginfo-install xsane*
#  yum --enablerepo=updates-testing update xsane*
#  debuginfo-install --enablerepo=updates-testing  xsane* (said No this time)
#  rpm -qa | grep xsane
#  debuginfo-install -d 9 --enablerepo=updates-testing  xsane*
#  rpm -qa | grep xsane

Full output is be attached, I just point out interesting info below:

#  rpm -qa | grep xsane

#  debuginfo-install xsane*
 xsane-debuginfo  i386   0.995-5.fc10  fedora-debuginfo  1.0 M 
  xsane-debuginfo.i386 0:0.995-5.fc10

#  yum --enablerepo=updates-testing update xsane*
 Package     Arch  Version       Repository       Size 
 xsane       i386  0.996-3.fc10  updates-testing  2.0 M 
 xsane-gimp  i386  0.996-3.fc10  updates-testing  258 k 

Transaction Summary
Install      0 Package(s)
Update       2 Package(s)
Remove       0 Package(s)

#  debuginfo-install --enablerepo=updates-testing  xsane*
 Package          Arch  Version       Repository                  Size 
 xsane-debuginfo  i386  0.995-5.fc10  fedora-debuginfo            1.0 M 
 xsane-debuginfo  i386  0.996-3.fc10  updates-testing-debuginfo   1.0 M 

Transaction Summary
Install      1 Package(s)                              
Update       1 Package(s)
Remove       0 Package(s)

And that is the problem. Why it wants to download xsane-debuginfo-0.995-5.fc10 
when it is already there? A said No this time to check what I actually have:
#  rpm -qa | grep xsane

You see it, it is there. So what happens when I say Yes:

#  debuginfo-install -d 9 --enablerepo=updates-testing  xsane*
Downloading Packages:
(1/2): xsane-debuginfo-0.995-5.fc10.i386.rpm          | 1.0 MB     00:00     
(2/2): xsane-debuginfo-0.996-3.fc10.i386.rpm          | 1.0 MB     00:00     
Total                                        1.2 MB/s | 2.1 MB     00:01

It downloaded both despite the fact I already have the older one.

  xsane-debuginfo.i386 0:0.995-5.fc10

  xsane-debuginfo.i386 0:0.996-3.fc10

Really? Just check:

# rpm -qa | grep xsane

No, not really. The 0.995-5 was actually removed, not installed.

Tomorrow I check on x86_64 with the same package.
Comment 5 James Antill 2009-02-09 14:14:19 EST
 Ok, so you had:

#  rpm -qa | grep xsane

...then you had (implied):

#  rpm -qa | grep xsane

...then you had:

#  rpm -qa | grep xsane

...at which point, running:

  sudo debuginfo-install --enablerepo=updates-testing 'xsane*'"

...asks to download both the old and new versions of xsane-debuginfo. I can't reproduce this atm. all that happens is that xsane-debuginfo moves into the "Updating:" section ... although atm. there are 13 other packages it needs to satisfy deps. for xsane-debuginfo, so maybe that fixes it?
Comment 6 James Antill 2009-02-09 14:29:42 EST
 Ok, I can reproduce the problem now. If I have all of the deps. installed before the debuginfo-install it does what you say above:

% sudo yum ls xsane\* 
Installed Packages
xsane.x86_64                            0.996-3.fc10                   installed
xsane-debuginfo.x86_64                  0.995-5.fc10                   installed
xsane-gimp.x86_64                       0.996-3.fc10                   installed
% sudo debuginfo-install --enablerepo=updates-testing xsane\*
 xsane-debuginfo   x86_64   0.995-5.fc10      fedora-debuginfo            1.1 M
 lcms-debuginfo    x86_64   1.17-6.fc10       fedora-debuginfo            809 k
 xsane-debuginfo   x86_64   0.996-3.fc10      updates-testing-debuginfo   1.1 M


 In upstream yum-utils there is a yum-auto-update-debuginfo plugin, which will solve your problem in the "best" way. I'll hunt this down too though.
Comment 7 James Antill 2009-02-09 14:33:36 EST
 And after a couple of moments tought the problem seems obvious:

% sudo debuginfo-install --enablerepo=updates-testing xsane xsane-debuginfo
 xsane-debuginfo   x86_64   0.995-5.fc10      fedora-debuginfo            1.1 M
 lcms-debuginfo    x86_64   1.17-6.fc10       fedora-debuginfo            809 k
 xsane-debuginfo   x86_64   0.996-3.fc10      updates-testing-debuginfo   1.1 M

...here we process "xsane" and that brings in xsane-debuginfo-0.996-3.fc10, and then we process "xsane-debuginfo-0.995-5.fc10" which has a base package of "xsane-0.995-5.fc10" which has a debuginfo of "xsane-debuginfo-0.995-5.fc10"  ... which isn't installed anymore because the update just marked it as "removed".

Comment 8 James Antill 2009-02-09 14:40:31 EST
 This works around this problem:

commit 7e6d520d260165f20e5d889fc6438d0482814a38
Author: James Antill <james@and.org>
Date:   Mon Feb 9 14:38:23 2009 -0500

    Simple hacky workaround for BZ 484603, debuginfo-install x x-debuginfo

diff --git a/debuginfo-install.py b/debuginfo-install.py
index 2dfc5b7..99cc177 100755
--- a/debuginfo-install.py
+++ b/debuginfo-install.py
@@ -84,6 +84,8 @@ class DebugInfoInstall(YumUtilBase):
     def di_try_install(self, po):
+        if po.name.endswith('-debuginfo'): # Wildcard matches produce this
+            return
         di_name = '%s-debuginfo' % po.name
         if self.pkgSack.searchNevra(name=di_name, arch=po.arch):
             test_name = di_name
Comment 9 Jaroslav Franek 2009-02-09 14:50:03 EST
Nice :-) Thank you.

I reckon the yum-auto-update-debuginfo is exactly what I need.

Note You need to log in before you can comment on or make changes to this bug.