Hide Forgot
Problem: People keep installing a debuginfo RPM that doesn't match the installed binary RPM, and then wonder why GDB refuses to use that debug info (GDB should also complain about the screwup, but thats past the event). Solution: The debug RPMs do not "require" that the correct corresponding binary is installed. For instance: $ rpm -qpR at-debuginfo-3.1.8-64_EL.ppc.rpm rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 it should also specify that it requires: at == 3.1.8-64_EL which is provided by the corresponding binary rpm: rpm -qp --provides at-3.1.8-64_EL.ppc.rpm config(at) = 3.1.8-64_EL at = 3.1.8-64_EL
See also bug #146957.
If at-debuginfo requires at = %{version}-%{release}, then an update to at without at-debuginfo causes a missing requirement and will pevent updating. Potentially leaving a vulnerable package around on the system Not all repositories for fedora carry debuginfo packages - for RHEL I'd need to confirm that we guarantee that -debuginfo is in RHN before this change, we'd also need it in redhat-rpm-config too.
- our support organization is supplying customers with debuginfo RPMs; so RHN or not we've got customers hitting this problem. - the dependency should be: foo-debug requires foo; and not foo requires foo-debug. That way, having foo installed doesn't force foo-debug to be installed. This is identical to glibc-devel requiring glibc, but not the reverse. - a system with a mismatched debuginfo rpm is in an inconsistent state. We should not be allowing customers to do that to their system. - as for updates, the customer should remove the debuginfo rpm before doing the update (or get a newer one) (outside the box, you could have RPM N+1 obsolete RPM-debuginfo N)
BTW, an update, without matching debug info, breaks debug functionality (leaving the system in an inconsistent state) - no need to remove the debuginfo. On the other hand, if the broken debug info is removed, the system is kept consistent and it's clear that a new debuginfo rpm is required.
Evil macros: %description\ %{?_enable_debug_packages:%{!?__debug_obsoletes:Obsoletes: %{?epoch:%{epoch}:}%{name}-debuginfo < %{version}-%{release}}}\ %global __debug_obsoletes 1\ %%description%{nil}
Note that the "main" %{name} package doesn't necessarily exist in all cases, so a simplistic "Requires: %{name}<whatever>" for all -debuginfos doesn't work.
rpm does not enable -debuginfo production by default, so this is a redhat-rpm-config, not rpm, problem.
Created attachment 145790 [details] base->debuginfo Conflicts based patch. # FIXME: It will never get satisfied with appended: .%{_target_cpu} %description\ %{?_enable_debug_packages:\ Conflicts: %{?epoch:%{epoch}:}%{name}-debuginfo < %{version}-%{release}\ Conflicts: %{?epoch:%{epoch}:}%{name}-debuginfo > %{version}-%{release}}\ %%description It goes the opposite way. If we cannot `debuginfo Requires basepackage=verrel' we can `basepackage Conflicts debuginfo<>verrel'. It will limit the installation of multiple versions of debuginfos but such case IMO does not need to be supported. It may require user interaction (`rpm -e *.debuginfo') in the case the appropriate upgraded debuginfos are currently not available. It was an intention (over `Obsoletes' methods) as the user should be notified if he is going to lose the manually installed debuginfos before - users installing debuginfos are not completely dumb to cannot type `rpm -e' anyway.
Created attachment 145791 [details] .src.rpm trivia fast debuginfo generating testing package.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
The arch FIXME part of the Comment 11 is the (upstream fixed) rpm Bug 235755. Forbidding installation of non-matching PKG and PKG-debuginfo versions is wrong as in the future (F10) we should have multi debuginfo versions installed. Therefore moved this problem to YUM as described in Bug 432806 Comment 8. This Bug should get WONTFIXed.