Bug 455875

Summary: debuginfo-install confused by architecture differences
Product: [Fedora] Fedora Reporter: Christopher Beland <beland>
Component: yum-utilsAssignee: Seth Vidal <skvidal>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: james.antill, jhutar, pmatilai, tim.lauridsen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-16 19:16:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Christopher Beland 2008-07-18 15:12:33 UTC
I have glibc-debuginfo-2.8-3.i686 and glibc-2.8-3.i686 installed.  I ran the
command "debuginfo-install `rpm -qa`" so I could be guaranteed of producing
useful stack traces in the event of a program crash.  This process downloads
over 700 packages, and then fails with the below errors.  It seems like
debuginfo-install should be able to figure out which architecture is needed;
isn't that important for debugging?

--

Traceback (most recent call last):
  File "/usr/bin/debuginfo-install", line 124, in <module>
    util = DebugInfoInstall()
  File "/usr/bin/debuginfo-install", line 42, in __init__
    self.main()
  File "/usr/bin/debuginfo-install", line 82, in main
    self.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 408, in doTransaction
    self.errorSummary(errstring)
yum.Errors.YumBaseError: Transaction Check Error:
  package glibc-debuginfo-2.8-3.i386 is already installed
  file /usr/lib/debug/lib/ld-2.8.so.debug from install of
glibc-debuginfo-2.8-3.i386 conflicts with file from package
glibc-debuginfo-2.8-3.i686
 

This is with yum-utils-1.1.14-4.fc9.noarch

Comment 1 Christopher Beland 2009-01-16 06:38:35 UTC
Now with yum-utils-1.1.19-1.fc11.noarch:

* If I do "debuginfo-install glibc-2.9.90-2.i686", I get:

Could not find debuginfo for main pkg: glibc-2.9.90-2.i686
Could not find debuginfo pkg for dependency package glibc-2.9.90-2.i686
(repeated lots of times)

* If I do "debuginfo-install glibc-2.9.90-2.x86_64", I get:

Installing:
 glibc-debuginfo      x86_64      2.9.90-2         rawhide-debuginfo       22 M

"uname -a" reports:

Linux free-spin.localdomain 2.6.29-0.28.rc1.fc11.x86_64 #1 SMP Sun Jan 11 20:52:37 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

This is a 64-bit machine, but doesn't it need to be able to install the 32-bit debuginfo packages in parallel?

Comment 2 James Antill 2009-01-16 16:00:43 UTC
Fedora doesn't ship multilib. debuginfo, so there's nolthing yum can do.
Is the first bug in this BZ still unfixed?

Comment 3 Christopher Beland 2009-01-16 17:56:11 UTC
The conflict problem is fixed; "debuginfo-install `rpm -qa`" works in current Rawhide.

So, if there is a crash in a 32-bit program, will it be undiagnosable due to lack of debugging symbols?  I suppose all of the Fedora code is available in 64 bits; the only stuff I have installed 32-bit is Adobe Acrobat and Flash.

I also get a ton of warnings from "debuginfo-install `rpm -qa`" for noarch packages; should I just ignore them, or should debuginfo-install handle them more gracefully?

Comment 4 James Antill 2009-01-16 19:16:05 UTC
Yeh, and in theory you can create a secdon debuginfo repo. pointing to the 32 one ... although probably noone tests how well that works.

Instead of warnings what would you like, no warning? Even though you've asked it to do something it can't?

You can also do either of:

 debuginfo-install \*
 debuginfo-install \*.x86_64

Comment 5 seth vidal 2009-01-16 19:20:00 UTC
keeping the warnings makes sense to me.

At the very least so someone who intentionally does:

debuginfo-install yum

can understand a little bit why it did nothing.

Comment 6 Christopher Beland 2009-01-16 19:50:50 UTC
OK, sounds like the best we can do for now, other than documenting that this is normal.  I've filed that request under bug 480385.  Thanks for your advice!