Executable-debuginfo conflicts when installing multiple arches of debuginfo

[Jeff Johnson]

Tracker

[Matt (matt-redhat-bugs)]

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

[Jeff (jeff-redhat-bugs)]

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.

[Matt (matt-redhat-bugs)]

(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 / .

[Jeff (jeff-redhat-bugs)]

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.

[Matt (matt-redhat-bugs)]

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.

[Bug (bug-redhat-bugs)]

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

[Matt (matt-redhat-bugs)]

The problem still occurs in Fedora 13.

[Jeff (jeff-redhat-bugs)]

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.

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Zoltan (zoltan-redhat-bugs)]

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?

[Panu (panu-redhat-bugs)]

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.