Bug 455875 - debuginfo-install confused by architecture differences
debuginfo-install confused by architecture differences
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-18 11:12 EDT by Christopher Beland
Modified: 2014-01-21 01:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-16 14:16:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Christopher Beland 2008-07-18 11:12:33 EDT
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 01:38:35 EST
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 11:00:43 EST
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 12:56:11 EST
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 14:16:05 EST
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 14:20:00 EST
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 14:50:50 EST
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!

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