Bug 528419 - Executable-debuginfo conflicts when installing multiple arches of debuginfo
Summary: Executable-debuginfo conflicts when installing multiple arches of debuginfo
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Fedora Packaging Toolset Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 573532 645310
TreeView+ depends on / blocked
 
Reported: 2009-10-12 04:08 UTC by Matt McCutchen
Modified: 2019-11-14 06:17 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 645310 (view as bug list)
Environment:
Last Closed: 2017-04-04 15:04:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1427970 0 unspecified CLOSED Include upstream debuginfo improvements to enable parallel installable debuginfo by default 2021-02-22 00:41:40 UTC

Internal Links: 1427970

Description Matt McCutchen 2009-10-12 04:08:18 UTC
Description of problem:
On an x86_64 system, it may be useful to install not only 32-bit and 64-bit versions of libraries but also the corresponding debuginfos so that both 32-bit and 64-bit binaries can be debugged.  If the library packages contain conflicting executables at the same path, rpm resolves the conflict in favor of the 64-bit executable.  However, this special rule does not apply to the _debuginfo_ of the executable, so parallel installation of the debuginfos hits a file conflict.  I think it would be natural to extend the special rule to executable debuginfos.

A good example package is openssl with the /usr/bin/openssl executable.

Version-Release number of selected component (if applicable):
rpm-4.7.1-1.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1. On an x86_64 system, enable the i386 repositories by making appropriately edited copies of /etc/yum.repos.d/fedora{,-updates}.repo .  (The x86_64 repos contain i386 libraries but not i386 debuginfos.)
2. yum install openssl-debuginfo.{i686,x86_64}

Actual results:
Successful installation with the debuginfo for the 64-bit /usr/bin/openssl ending up at /usr/lib/debug/usr/bin/openssl.debug .

Expected results:
Transaction Check Error:
  file /usr/lib/debug/usr/bin/openssl.debug from install of openssl-debuginfo-0.9.8k-5.fc11.i686 conflicts with file from package openssl-debuginfo-0.9.8k-5.fc11.x86_64

Comment 1 Jeff Johnson 2009-10-17 03:54:35 UTC
You're the first to request both both e;f32/elf64 that I recall.

The start of a fix (consistent with other multliib conventions) would be to
have both /usr/lib/debug as well as /usr/lib64/debug trees
to save debugging symbols.

But that path convention would need to be adopted by GDB
as well as build tools, which isn't going to happen soon.

Comment 2 Matt McCutchen 2009-10-18 04:21:27 UTC
(In reply to comment #1)
> The start of a fix (consistent with other multliib conventions) would be to
> have both /usr/lib/debug as well as /usr/lib64/debug trees
> to save debugging symbols.

I don't see the point of that.  The /usr/lib/debug tree is parallel to / and has its own subdirs /usr/lib/debug/usr/lib and /usr/lib/debug/usr/lib64 .  I.e., the "lib" in /usr/lib/debug is not indicating an architecture, so there is no need to fork it for multiple architectures.

All I'm proposing is that the rule in RPM that lets a 64-bit executable replace a 32-bit one should be extended to allow a 64-bit executable *debuginfo* to replace a 32-bit one.  Then I'll be able to parallel-install debuginfos, and the result under /usr/lib/debug will mirror / .

Comment 3 Jeff Johnson 2009-10-18 04:47:10 UTC
Replacing will have exactly the same behavior with "missing"
that you find unacceptable in bz #528383. Why bother solving
one problem that by instantly creating another issue? That
makes little sense to me.

And replacing forces one to choose one or the other multiplib
for debugging; there are developers who want both debug
symbols installed.

Comment 4 Matt McCutchen 2009-10-18 05:16:20 UTC
Look, there are two separate issues here:

1. Executables replace each other.

2. Executable debuginfos don't work the same way as executables.

This bug is about #2.

Comment 5 Bug Zapper 2010-04-28 10:48:05 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Matt McCutchen 2010-06-16 13:59:05 UTC
The problem still occurs in Fedora 13.

Comment 7 Jeff Johnson 2010-06-16 14:06:57 UTC
Meanwhile, -debuginfo appears about to change to eliminate
duplicated unnormalized data stored in 2 paths on the file system.
The ramifications of changing the paths/symlinks to DWARF symbols
make discussing automagic file conflict resolution for paths contained
in -debuginfo packages (your point 2) in comment #4)
rather more complicated than droning
       The problem still occurs in Fedora 12345678.

But
    Patches cheerfully accepted.
as always.

Comment 8 Fedora Admin XMLRPC Client 2012-04-13 23:09:07 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Fedora Admin XMLRPC Client 2012-04-13 23:11:59 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Zoltan Boszormenyi 2013-10-15 13:53:58 UTC
I ran into the same problem. Wouldn't it be a solution to change /usr/lib/rpm/find-debuginfo.sh so the /usr/lib/debug path is not hardcoded?

Comment 11 Panu Matilainen 2017-04-04 15:04:46 UTC
This should be fixed in rawhide as of packages built with rpm >= 4.13.0.1-4. So F27 should have parallel-installable debuginfo packages, assuming there is a mass-rebuild.


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